Claim OwnershipSystem Design
Subscribed: 197Played: 1,247
Subscribe
© 2021 System Design
Description
Software Engineers Wes Moncrief and Kevin Li discuss aspects of the system design interview, as well as related topics in designing large and interesting software architectures. If you're new here, I'd suggest starting with the episode "Facebook Timeline Interview". I'll also note that our first few episodes had lower quality audio than our subsequent episodes.We'd love to hear any listener feedback - email us at thesystemdesignpodcast@gmail.com
6 Episodes
Reverse
1Kevin 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/ https://redis.io/
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-databases-cp-or-ap.htmlMongoDB - https://docs.mongodb.com/manual/introduction/
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/
Download from Google Play
Download from App Store
United States
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!
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!