Kevin asks Wes to design Dropbox, with an emphasis on designing the data model and storage techniques to scale out.Helpful links:https://www.geeksforgeeks.org/design-dropbox-a-system-design-interview-question/https://www.youtube.com/watch?v=PE4gwstWhmchttps://developer.mozilla.org/en-US/docs/Web/API/WebSockets_APIhttps://www.ibm.com/cloud/learn/object-storage
As Kevin prepares to start a new job at Instacart, he explains some ideas around how a company like Instacart could employ caching to improve the scalability of their services.Show notes:https://medium.com/datadriveninvestor/all-things-caching-use-cases-benefits-strategies-choosing-a-caching-technology-exploring-fa6c1f2e93aahttps://ieftimov.com/post/when-why-least-frequently-used-cache-implementation-golang/https://github.com/donnemartin/system-design-primer#cachehttps://memcached.org/ ...
Wes and Kevin talk about message queues, the problems they solve, and how they work. https://github.com/donnemartin/system-design-primerhttp://highscalability.com/all-time-favorites/https://netflixtechblog.com/https://www.rabbitmq.com/tutorials/tutorial-one-python.htmlP.S., Wes learned how to edit podcasts better thanks to this guide - https://podigy.co/podcast-editing-guide/, hopefully this podcast has the best audio quality yet!
Breaking away from the interview format, Wes and Kevin deep dive into SQL vs noSQL databases.Show notes:ACID compliance - https://mariadb.com/resources/blog/acid-compliance-what-it-means-and-why-you-should-careCAP theorem https://www.ibm.com/cloud/learn/cap-theoremhttps://mwhittaker.github.io/blog/an_illustrated_proof_of_the_cap_theoremCool article explaining the problem with saying you can have 2 out of 3 properties of CAPhttp://martin.kleppmann.com/2015/05/11/please-stop-calling-databa...
Wes asks Kevin to design the Facebook/Twitter Timeline with an emphasis on scaling to a large number of users.I'd encourage you to pause where relevant to try to think through these designs yourself - it really helps the content sink in.Helpful LinksRabbitMQ quick start documentation - https://www.rabbitmq.com/getstarted.htmlApache Kafka introductinon - https://kafka.apache.org/intro
In our first episode, Kevin gives Wes a mock interview on how to design google docs. Helpful linksThe git storage technique we referenced is described in detail here - https://hypirion.com/musings/understanding-persistent-vector-pt-1 (Note that this is not git, but the same technique applies)Website with algorithm for merge conflict resolution - https://operational-transformation.github.io/
Rajat Saxena
Question: can something like Kafka take care of ALL the requirements for this use case? - it can handle large volume of data - it is resilient and can handle failures - each user could be a subscriber and when they login they just pull the unread statuses in their queue - each user's queue can handle chronology as well - for the celebrity case, it is a matter of heavy writes but eventually the message queue will get around to it Let me know your thoughts!
Rajat Saxena
All that time during the discussion about postStatus() I kept thinking "message queue, message queue" and eventually Wes brought it up :) This is my first time tuning into this podcast and was a good listen. I'll be back. Good luck!