{"id":"practice-questions","title":"Practice questions","sections":[{"id":"overview","title":"Overview","html":"<p>Reading about system design teaches you the parts. Answering questions out loud teaches you to use them. This chapter is a bank of questions to practise on, with pointers to the chapters that help and to articles that show how real companies solved the same problem.</p>\n<p>Here is one way to practise a question, say \"Design a chat app like WhatsApp\":</p>\n<ol>\n<li><strong>Set a timer for 45 minutes.</strong> That's about how long a real interview gives you.</li>\n<li><strong>Follow the four steps</strong> from <a href=\"/learn/system-design-interview\">The system design interview, step by step</a>: outline use cases and constraints, sketch a high-level design, design the core components, then scale it.</li>\n<li><strong>Say your estimates out loud.</strong> How many messages a day, how many people online at once, how much storage a year. Write the arithmetic down as you go, the way you would on a whiteboard. The <a href=\"/learn/estimation\">estimation</a> chapter and <a href=\"/learn/numbers-to-know\">numbers to know</a> help here.</li>\n<li><strong>Compare.</strong> When the timer stops, read the worked design if the handbook has one, or the references listed with the question. Note what you missed and what you'd do differently.</li>\n</ol>\n<p>The chapter has four parts:</p>\n<ul>\n<li><strong>Worked designs in this handbook</strong> lists every question the handbook answers in full, with what each one teaches. Start there: you can check your answer against a complete design laid out in the same four steps.</li>\n<li><strong>More system design questions</strong> groups further questions by theme. For each one you'll find what makes it hard, which chapters help, and references that are still online.</li>\n<li><strong>More object-oriented design questions</strong> covers class-design questions, where you write the classes and methods for one program instead of drawing a distributed system.</li>\n<li><strong>How to practise with these</strong> gives a simple plan, a checklist for reviewing your own answers, and tips for practising with a partner.</li>\n</ul>","headings":[]},{"id":"worked-designs-in-this-handbook","title":"Worked designs in this handbook","html":"<h3 id=\"worked-designs-in-this-handbook\">Worked designs in this handbook</h3>\n<p>These chapters each take one question from requirements to a scaled design. The system design chapters follow the same four steps you'll use in an interview, so you can compare your answer with one laid out the same way.</p>\n<h4 id=\"system-design-questions\">System design questions</h4>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n<div class=\"table-wrap\"><table><thead><tr><th>Question</th><th>What it teaches</th></tr></thead><tbody><tr><td><a href=\"/learn/design-pastebin\">Design a text-sharing service like Pastebin</a></td><td>Keeping small records (code, expiry) apart from the larger text they point to, cleaning up expired data, and serving a read-heavy service. Also asked as \"Design Bit.ly\", which is closer to the URL shortener below.</td></tr><tr><td><a href=\"/learn/design-twitter\">Design the Twitter timeline and search</a></td><td>Where to do the work for a feed: when a post is written (fan-out on write) or when a timeline is read, and what to do about accounts with millions of followers. Also asked as \"Design the Facebook feed and search\".</td></tr><tr><td><a href=\"/learn/design-web-crawler\">Design a web crawler</a></td><td>Managing a to-do list of billions of links, skipping duplicate pages, and crawling politely without overloading any one site.</td></tr><tr><td><a href=\"/learn/design-mint\">Design a personal finance tracker like Mint</a></td><td>Pulling data from outside systems in background workers, categorising it, and splitting a write-heavy workload from the reads users see.</td></tr><tr><td><a href=\"/learn/design-social-graph\">Design the data structures for a social network</a></td><td>Finding the shortest path between two people when friend lists are spread across many servers, while keeping the number of network calls small.</td></tr><tr><td><a href=\"/learn/design-query-cache\">Design a key-value cache for a search engine's query results</a></td><td>An in-memory cache with least-recently-used eviction, spread over many machines, with a plan for hot keys and stale results.</td></tr><tr><td><a href=\"/learn/design-sales-rank\">Design Amazon's sales rank by category</a></td><td>Separating a large, slow batch job that computes an answer from a small, fast path that serves it.</td></tr><tr><td><a href=\"/learn/design-scaling-aws\">Design a system that scales to millions of users on AWS</a></td><td>Growing one site from a single server to many, one bottleneck at a time, and knowing when each fix is worth its cost.</td></tr><tr><td><a href=\"/learn/design-url-shortener\">Design a URL shortener (like TinyURL or Bitly)</a></td><td>Generating short codes that never collide, choosing a redirect status code, sharding a table with billions of rows, and counting clicks cheaply.</td></tr><tr><td><a href=\"/learn/design-social-news-feed\">Design a social media news feed</a></td><td>Push versus pull feeds, caching feeds for hundreds of millions of users, paging through a list that keeps changing, and ranking.</td></tr><tr><td><a href=\"/learn/design-gaming-leaderboard\">Design a real-time gaming leaderboard</a></td><td>Answering \"what's my rank?\" among millions of players quickly, with sorted sets built on skip lists, and breaking ties fairly.</td></tr><tr><td><a href=\"/learn/design-payment-system\">Design a payment system and gateway</a></td><td>Making retries safe with idempotency keys, tracking each payment in a state machine, keeping a double-entry ledger, and reconciling with outside providers.</td></tr><tr><td><a href=\"/learn/design-collaborative-document\">Design a collaborative document editor</a></td><td>Merging edits that two people make at the same moment, with operational transformation or CRDTs, so every screen ends up showing the same text.</td></tr><tr><td><a href=\"/learn/design-search-engine\">Design a web search engine</a></td><td>Building an inverted index, splitting it across machines, and ranking results within a couple of hundred milliseconds.</td></tr><tr><td><a href=\"/learn/design-recommendation-system\">Design a personalized recommendation system</a></td><td>Narrowing a catalog of millions of items to twenty in stages, so the expensive model only scores a few hundred candidates.</td></tr><tr><td><a href=\"/learn/design-key-value-store\">Design a distributed key-value store</a></td><td>Partitioning, replication, quorums, conflict resolution and failure detection, all in one design.</td></tr><tr><td><a href=\"/learn/design-notification-system\">Design a notification system</a></td><td>Queues, retries, deduplication and rate limits across several outside providers, without letting a marketing blast delay a login code.</td></tr><tr><td><a href=\"/learn/design-chat-system\">Design a chat system</a></td><td>Long-lived connections, message ordering, delivery and read receipts, and keeping several devices per user in sync.</td></tr><tr><td><a href=\"/learn/design-autocomplete\">Design search autocomplete (typeahead)</a></td><td>Separating an offline pipeline that builds suggestions from an online lookup that answers in milliseconds, and caching almost everything.</td></tr><tr><td><a href=\"/learn/design-video-streaming\">Design a video streaming platform</a></td><td>Uploading very large files reliably, transcoding in parallel, adaptive bitrate streaming, and why bandwidth cost shapes the design.</td></tr><tr><td><a href=\"/learn/design-file-sync\">Design a file sync service (like Dropbox or Google Drive)</a></td><td>Keeping strongly consistent file metadata apart from file content, splitting files into blocks, and handling conflicts from offline edits.</td></tr></tbody></table></div>\n<h4 id=\"object-oriented-design-questions\">Object-oriented design questions</h4>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n<div class=\"table-wrap\"><table><thead><tr><th>Question</th><th>What it teaches</th></tr></thead><tbody><tr><td><a href=\"/learn/ood-hash-table\">Design a hash map</a></td><td>Turning a key into an array index, handling collisions, and growing the table as it fills.</td></tr><tr><td><a href=\"/learn/ood-lru-cache\">Design an LRU cache</a></td><td>Combining a hash map with a linked list so that lookups and evictions both take constant time.</td></tr><tr><td><a href=\"/learn/ood-call-center\">Design a call center</a></td><td>Escalating work through a chain of employees and queuing callers when everyone is busy.</td></tr><tr><td><a href=\"/learn/ood-deck-of-cards\">Design a deck of cards</a></td><td>Modelling a general structure once and letting each game (such as blackjack) give it its own rules through inheritance.</td></tr><tr><td><a href=\"/learn/ood-parking-lot\">Design a parking lot</a></td><td>Matching vehicles of different sizes to spots, including a vehicle that needs several spots side by side.</td></tr><tr><td><a href=\"/learn/ood-online-chat\">Design a chat server</a></td><td>Users, friend requests, private chats and group chats as classes, with rules about who may post where.</td></tr></tbody></table></div>","headings":[{"id":"worked-designs-in-this-handbook","title":"Worked designs in this handbook","depth":3},{"id":"system-design-questions","title":"System design questions","depth":4},{"id":"object-oriented-design-questions","title":"Object-oriented design questions","depth":4}]},{"id":"more-system-design-questions","title":"More system design questions","html":"<h3 id=\"more-system-design-questions\">More system design questions</h3>\n<p>The handbook doesn't work these questions through in full. Each one lists what makes it hard, the chapters that cover the parts you'll need, and references that show how others have answered it. Most of them overlap with a worked design, so do that one first and then try the variation.</p>\n<p>The references were checked when this chapter was written. Some are old. Treat the numbers in them as a snapshot of that time, and read them for the reasoning.</p>\n<h4 id=\"storage-caching-and-file-systems\">Storage, caching and file systems</h4>\n<p><strong>Design a file sync service like Dropbox.</strong></p>\n<ul>\n<li>What makes it hard: file metadata must stay consistent across every device, while the file contents are large and need to move with as little bandwidth as possible. Two devices that edit the same file offline will conflict when they reconnect.</li>\n<li>Chapters: <a href=\"/learn/design-file-sync\">Design a file sync service</a>, <a href=\"/learn/nosql-databases\">NoSQL databases</a>, <a href=\"/learn/cap-and-consistency\">CAP and consistency</a>.</li>\n<li>References: <a href=\"https://www.youtube.com/watch?v=PE4gwstWhmc\" target=\"_blank\" rel=\"noopener noreferrer\">How We've Scaled Dropbox</a>, a talk on Dropbox's growth posted on Stanford's YouTube channel.</li>\n</ul>\n<p><strong>Design a key-value store like Redis.</strong></p>\n<ul>\n<li>What makes it hard: on one machine it is a hash table. Across many machines you have to decide how keys are split, how many copies each key has, and what a read returns while copies disagree.</li>\n<li>Chapters: <a href=\"/learn/design-key-value-store\">Design a distributed key-value store</a>, <a href=\"/learn/ood-hash-table\">Design a hash map</a>, <a href=\"/learn/consistent-hashing\">Consistent hashing</a>, <a href=\"/learn/nosql-databases\">NoSQL databases</a>.</li>\n<li>References: <a href=\"https://codecapsule.com/2012/11/07/ikvs-implementing-a-key-value-store-table-of-contents/\" target=\"_blank\" rel=\"noopener noreferrer\">Implementing a Key-Value Store</a>, Emmanuel Goossaert's article series on building one from scratch (it became the KingDB project). <a href=\"https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf\" target=\"_blank\" rel=\"noopener noreferrer\">Dynamo: Amazon's Highly Available Key-value Store</a>, the 2007 paper behind many distributed key-value stores.</li>\n</ul>\n<p><strong>Design a cache system like Memcached.</strong></p>\n<ul>\n<li>What makes it hard: memory is limited, so you need an eviction policy. Once the cache spans many servers, adding or removing a server must not move most of the keys, and many clients asking for the same missing key at once must not all hit the database.</li>\n<li>Chapters: <a href=\"/learn/cache\">Caching</a>, <a href=\"/learn/ood-lru-cache\">Design an LRU cache</a>, <a href=\"/learn/design-query-cache\">Design a key-value cache for a search engine</a>, <a href=\"/learn/consistent-hashing\">Consistent hashing</a>.</li>\n<li>References: <a href=\"https://www.slideshare.net/oemebamo/introduction-to-memcached\" target=\"_blank\" rel=\"noopener noreferrer\">Introduction to memcached</a>, Jurriaan Persyn's slides on caching basics, memcached's design and invalidation strategies. <a href=\"https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/nishtala\" target=\"_blank\" rel=\"noopener noreferrer\">Scaling Memcache at Facebook</a>, a 2013 NSDI paper on running memcached as a very large shared cache.</li>\n</ul>\n<p><strong>Design a garbage collection system.</strong></p>\n<ul>\n<li>What makes it hard: this question is about the memory of one running program. The collector has to find every object the program can still reach, free the rest, and do it without pausing the program for too long.</li>\n<li>Chapters: <a href=\"/learn/ood-hash-table\">Design a hash map</a> for practice with low-level data structures, and <a href=\"/learn/performance-and-latency\">Performance and latency</a> for the cost of long pauses.</li>\n<li>References: <a href=\"https://journal.stuffwithstuff.com/2013/12/08/babys-first-garbage-collector/\" target=\"_blank\" rel=\"noopener noreferrer\">Baby's First Garbage Collector</a>, Bob Nystrom's short walk through a mark-and-sweep collector in C. <a href=\"https://web.archive.org/web/20171107023757/https://courses.cs.washington.edu/courses/csep521/07wi/prj/rick.pdf\" target=\"_blank\" rel=\"noopener noreferrer\">Garbage Collection Algorithms</a>, Rick Byers's 2007 University of Washington survey of collection algorithms. The original link now asks for a university login, so this is an archived copy.</li>\n</ul>\n<p><strong>Design a system that serves data from multiple data centers.</strong></p>\n<ul>\n<li>What makes it hard: copies of the data are far apart, so every write either waits for the other sites (slow but consistent) or doesn't (fast, but a failure can lose recent writes or leave sites disagreeing).</li>\n<li>Chapters: <a href=\"/learn/availability\">Availability</a>, <a href=\"/learn/cap-and-consistency\">CAP and consistency</a>, <a href=\"/learn/consensus\">Consensus</a>, <a href=\"/learn/relational-databases\">Relational databases</a> for replication, <a href=\"/learn/dns-and-cdn\">DNS and CDN</a> for sending users to the nearest site.</li>\n<li>References: <a href=\"https://highscalability.com/how-google-serves-data-from-multiple-datacenters/\" target=\"_blank\" rel=\"noopener noreferrer\">How Google Serves Data from Multiple Datacenters</a>, High Scalability's 2009 summary of Ryan Barrett's Google I/O talk. It compares backups, primary-replica copying, multi-primary writes, two-phase commit and Paxos.</li>\n</ul>\n<p><strong>Design a content delivery network like Cloudflare.</strong></p>\n<ul>\n<li>What makes it hard: thousands of edge servers must decide what to cache, users must be sent to a nearby healthy server, and the origin must be protected when a page suddenly becomes popular.</li>\n<li>Chapters: <a href=\"/learn/dns-and-cdn\">DNS and CDN</a>, <a href=\"/learn/cache\">Caching</a>, <a href=\"/learn/load-balancing\">Load balancing</a>, <a href=\"/learn/design-video-streaming\">Design a video streaming platform</a>.</li>\n<li>References: <a href=\"https://kilthub.cmu.edu/articles/journal_contribution/Globally_distributed_content_delivery/6605972\" target=\"_blank\" rel=\"noopener noreferrer\">Globally distributed content delivery</a>, a 2002 IEEE Internet Computing paper by Dilley, Maggs and others describing the Akamai network, which launched in early 1999.</li>\n</ul>\n<h4 id=\"social-messaging-and-collaboration\">Social, messaging and collaboration</h4>\n<p><strong>Design a chat app like WhatsApp.</strong></p>\n<ul>\n<li>What makes it hard: hundreds of millions of phones each hold an open connection, messages must arrive in order and exactly once from the user's point of view, and a phone that was offline must catch up when it reconnects.</li>\n<li>Chapters: <a href=\"/learn/design-chat-system\">Design a chat system</a>, <a href=\"/learn/realtime\">Real-time communication</a>, <a href=\"/learn/unique-ids\">Unique IDs</a>, <a href=\"/learn/ood-online-chat\">Design a chat server</a>.</li>\n<li>References: <a href=\"https://highscalability.com/the-whatsapp-architecture-facebook-bought-for-19-billion/\" target=\"_blank\" rel=\"noopener noreferrer\">The WhatsApp Architecture Facebook Bought For $19 Billion</a>, High Scalability's 2014 write-up. It describes servers written almost entirely in Erlang on FreeBSD, and cites 50 billion messages a day handled by 32 engineers at the time.</li>\n</ul>\n<p><strong>Design the Facebook chat function.</strong></p>\n<ul>\n<li>What makes it hard: presence. Telling every friend each time someone comes online, goes idle or leaves costs more than delivering the messages, and the cost grows with the size of friend lists.</li>\n<li>Chapters: <a href=\"/learn/design-chat-system\">Design a chat system</a>, <a href=\"/learn/realtime\">Real-time communication</a>, <a href=\"/learn/queues-and-async\">Queues and async work</a>.</li>\n<li>References: <a href=\"https://engineering.fb.com/2008/05/13/web/facebook-chat/\" target=\"_blank\" rel=\"noopener noreferrer\">Facebook Chat</a>, Eugene Letuchy's 2008 post on why presence was the costly part, and on the long-polling server written in Erlang. <a href=\"http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf\" target=\"_blank\" rel=\"noopener noreferrer\">Erlang at Facebook</a>, his 2009 slides on the chat architecture and its rollout.</li>\n</ul>\n<p><strong>Design a picture sharing system like Instagram.</strong></p>\n<ul>\n<li>What makes it hard: photos are large and written once, while the metadata around them (likes, comments, follows) is small and changes constantly. Each needs a different store, and every upload has to produce several sizes and reach a CDN.</li>\n<li>Chapters: <a href=\"/learn/design-social-news-feed\">Design a social media news feed</a>, <a href=\"/learn/design-video-streaming\">Design a video streaming platform</a> for the upload pipeline, <a href=\"/learn/dns-and-cdn\">DNS and CDN</a>, <a href=\"/learn/relational-databases\">Relational databases</a> for sharding.</li>\n<li>References: <a href=\"https://highscalability.com/flickr-architecture/\" target=\"_blank\" rel=\"noopener noreferrer\">Flickr Architecture</a>, High Scalability's 2007 write-up on sharding users across databases and caching heavily. <a href=\"https://highscalability.com/instagram-architecture-14-million-users-terabytes-of-photos/\" target=\"_blank\" rel=\"noopener noreferrer\">Instagram Architecture: 14 Million users, Terabytes of Photos</a>, the 2011 write-up: photos in Amazon S3 behind CloudFront, metadata in PostgreSQL, feeds in Redis.</li>\n</ul>\n<p><strong>Design the Facebook news feed function.</strong></p>\n<ul>\n<li>What makes it hard: a person may follow hundreds of sources, and loading the feed must not mean hundreds of database reads. You choose between building feeds when people post or when they read, and then rank the result.</li>\n<li>Chapters: <a href=\"/learn/design-social-news-feed\">Design a social media news feed</a>, <a href=\"/learn/design-twitter\">Design the Twitter timeline and search</a>, <a href=\"/learn/cache\">Caching</a>.</li>\n<li>References: <a href=\"https://www.quora.com/What-are-the-best-practices-for-building-something-like-a-news-feed\" target=\"_blank\" rel=\"noopener noreferrer\">What are the best practices for building something like a news feed?</a> and <a href=\"https://www.quora.com/Activity-Streams/What-are-the-scaling-issues-to-keep-in-mind-while-developing-a-social-network-feed\" target=\"_blank\" rel=\"noopener noreferrer\">What are the scaling issues to keep in mind while developing a social network feed?</a>, two Quora threads; the second has an answer from an engineer who worked on Facebook's News Feed. <a href=\"https://www.slideshare.net/danmckinley/etsy-activity-feeds-architecture\" target=\"_blank\" rel=\"noopener noreferrer\">Etsy Activity Feeds Architecture</a>, Dan McKinley's 2011 slides on building feeds offline and caching them.</li>\n</ul>\n<p><strong>Design the Facebook timeline function.</strong></p>\n<ul>\n<li>What makes it hard: a profile page shows years of activity, and the normalized data behind it would need many joins per page. Fast pages need the data reshaped for the way it is read.</li>\n<li>Chapters: <a href=\"/learn/relational-databases\">Relational databases</a> for denormalization, <a href=\"/learn/cache\">Caching</a>, <a href=\"/learn/design-social-news-feed\">Design a social media news feed</a>.</li>\n<li>References: <a href=\"https://engineering.fb.com/2012/01/05/web/building-timeline-scaling-up-to-hold-your-life-story/\" target=\"_blank\" rel=\"noopener noreferrer\">Building Timeline: Scaling up to hold your life story</a>, Ryan Mack's 2012 post on denormalizing the data, storing it in MySQL and caching it in memcached. <a href=\"https://highscalability.com/facebook-timeline-brought-to-you-by-the-power-of-denormaliza/\" target=\"_blank\" rel=\"noopener noreferrer\">Facebook Timeline: Brought to You by the Power of Denormalization</a>, High Scalability's summary of that post.</li>\n</ul>\n<p><strong>Design Google Docs.</strong></p>\n<ul>\n<li>What makes it hard: two people can type into the same sentence at the same moment, each against a version of the text that doesn't include the other's edit. The system must merge both without locking and without losing either.</li>\n<li>Chapters: <a href=\"/learn/design-collaborative-document\">Design a collaborative document editor</a>, <a href=\"/learn/realtime\">Real-time communication</a>.</li>\n<li>References: <a href=\"https://neil.fraser.name/writing/sync/\" target=\"_blank\" rel=\"noopener noreferrer\">Differential Synchronization</a>, Neil Fraser's 2009 paper on keeping copies of a document in sync with repeated diff and patch. <a href=\"https://code.google.com/archive/p/google-mobwrite\" target=\"_blank\" rel=\"noopener noreferrer\">google-mobwrite</a>, the archived code of MobWrite, a web editor built on that algorithm.</li>\n</ul>\n<h4 id=\"search-ranking-and-recommendations\">Search, ranking and recommendations</h4>\n<p><strong>Design a search engine like Google.</strong></p>\n<ul>\n<li>What makes it hard: the index is far too large for one machine, a query must reach hundreds of machines and come back in a fraction of a second, and ranking decides whether the results are any good.</li>\n<li>Chapters: <a href=\"/learn/design-search-engine\">Design a web search engine</a>, <a href=\"/learn/design-web-crawler\">Design a web crawler</a>, <a href=\"/learn/design-query-cache\">Design a key-value cache for a search engine</a>.</li>\n<li>References: <a href=\"http://infolab.stanford.edu/~backrub/google.html\" target=\"_blank\" rel=\"noopener noreferrer\">The Anatomy of a Large-Scale Hypertextual Web Search Engine</a>, Sergey Brin and Larry Page's paper describing the first Google. <a href=\"https://queue.acm.org/doi/10.1145/988392.988407\" target=\"_blank\" rel=\"noopener noreferrer\">Why Writing Your Own Search Engine Is Hard</a>, Anna Patterson's 2004 ACM Queue article on crawling, indexing and serving on a budget. <a href=\"https://softwareengineering.stackexchange.com/questions/38324/how-would-you-implement-google-search\" target=\"_blank\" rel=\"noopener noreferrer\">How would you implement Google Search?</a>, a Stack Exchange thread that answers it as an interview question. <a href=\"https://www.ardendertat.com/2012/01/11/implementing-search-engines/\" target=\"_blank\" rel=\"noopener noreferrer\">Implementing Search Engines</a>, Arden Dertat's 2012 series that builds a small search engine in Python, with TF-IDF ranking.</li>\n</ul>\n<p><strong>Design a scalable web crawler like Google's.</strong></p>\n<ul>\n<li>What makes it hard: the list of links to visit grows faster than you can fetch it, the same page appears under many addresses, and you must not overload any one site.</li>\n<li>Chapters: <a href=\"/learn/design-web-crawler\">Design a web crawler</a>, <a href=\"/learn/design-search-engine\">Design a web search engine</a>, <a href=\"/learn/queues-and-async\">Queues and async work</a>.</li>\n<li>References: <a href=\"https://www.quora.com/How-can-I-build-a-web-crawler-from-scratch-What-language-or-framework-would-you-recommend\" target=\"_blank\" rel=\"noopener noreferrer\">How can I build a web crawler from scratch?</a>, a Quora thread.</li>\n</ul>\n<p><strong>Design a graph search function like Facebook's.</strong></p>\n<ul>\n<li>What makes it hard: a query such as \"friends of mine who live in Paris and like jazz\" combines several relationships, and the answer must be personal to the searcher yet come back as fast as a normal search.</li>\n<li>Chapters: <a href=\"/learn/design-social-graph\">Design the data structures for a social network</a>, <a href=\"/learn/design-search-engine\">Design a web search engine</a>, <a href=\"/learn/design-autocomplete\">Design search autocomplete</a>.</li>\n<li>References: three 2013 Facebook engineering posts: <a href=\"https://engineering.fb.com/2013/03/06/core-infra/under-the-hood-building-out-the-infrastructure-for-graph-search/\" target=\"_blank\" rel=\"noopener noreferrer\">Building out the infrastructure for Graph Search</a>, <a href=\"https://engineering.fb.com/2013/03/14/core-infra/under-the-hood-indexing-and-ranking-in-graph-search/\" target=\"_blank\" rel=\"noopener noreferrer\">Indexing and ranking in Graph Search</a> and <a href=\"https://engineering.fb.com/2013/04/29/web/under-the-hood-the-natural-language-interface-of-graph-search/\" target=\"_blank\" rel=\"noopener noreferrer\">The natural language interface of Graph Search</a>.</li>\n</ul>\n<p><strong>Design a trending topic system like Twitter's.</strong></p>\n<ul>\n<li>What makes it hard: you count a firehose of events over a sliding window, and \"trending\" means rising faster than usual, which is different from being popular. Counts must be merged across many machines into one ranked list.</li>\n<li>Chapters: <a href=\"/learn/design-sales-rank\">Design Amazon's sales rank by category</a>, <a href=\"/learn/event-streaming\">Event streaming</a>, <a href=\"/learn/batch-processing\">Batch processing</a>.</li>\n<li>References: <a href=\"https://michael-noll.com/blog/2013/01/18/implementing-real-time-trending-topics-in-storm/\" target=\"_blank\" rel=\"noopener noreferrer\">Implementing Real-Time Trending Topics with a Distributed Rolling Count Algorithm in Storm</a>, Michael Noll's 2013 post on sliding-window counts merged into a top-N list. <a href=\"https://snikolov.wordpress.com/2012/11/14/early-detection-of-twitter-trends/\" target=\"_blank\" rel=\"noopener noreferrer\">Early detection of Twitter trends explained</a>, Stanislav Nikolov's 2012 post on spotting trends by comparing a topic's activity with past examples.</li>\n</ul>\n<p><strong>Return the top k requests during a time interval.</strong></p>\n<ul>\n<li>What makes it hard: there may be too many distinct requests to count each one exactly in memory, so you need an approximate counter with known error. Old requests must also drop out as the window slides.</li>\n<li>Chapters: <a href=\"/learn/design-sales-rank\">Design Amazon's sales rank by category</a>, <a href=\"/learn/design-gaming-leaderboard\">Design a real-time gaming leaderboard</a>, <a href=\"/learn/event-streaming\">Event streaming</a>.</li>\n<li>References: <a href=\"https://www.cs.ucsb.edu/sites/default/files/documents/2005-23.pdf\" target=\"_blank\" rel=\"noopener noreferrer\">Efficient Computation of Frequent and Top-k Elements in Data Streams</a>, Metwally, Agrawal and El Abbadi's 2005 paper on finding the top k items in limited space. <a href=\"https://davis.wpi.edu/xmdv/docs/EDBT11-diyang.pdf\" target=\"_blank\" rel=\"noopener noreferrer\">An Optimal Strategy for Monitoring Top-k Queries in Streaming Windows</a>, Yang and others' 2011 EDBT paper on keeping a top-k answer up to date as a window slides.</li>\n</ul>\n<p><strong>Design a recommendation system like Amazon's.</strong></p>\n<ul>\n<li>What makes it hard: the catalog is huge and a good model is expensive per item, so you can't score every item for every request. You also need fresh signals (what the user just clicked) alongside long-term taste.</li>\n<li>Chapters: <a href=\"/learn/design-recommendation-system\">Design a personalized recommendation system</a>, <a href=\"/learn/batch-processing\">Batch processing</a>, <a href=\"/learn/cache\">Caching</a>.</li>\n<li>References: <a href=\"https://web.archive.org/web/20170406065247/http://tech.hulu.com/blog/2011/09/19/recommendation-system.html\" target=\"_blank\" rel=\"noopener noreferrer\">Hulu's Recommendation System</a>, a 2011 Hulu engineering post (archived copy). <a href=\"https://web.archive.org/web/20161219165858/http://ijcai13.org/files/tutorial_slides/td3.pdf\" target=\"_blank\" rel=\"noopener noreferrer\">Tutorial: Recommender Systems</a>, Dietmar Jannach and Gerhard Friedrich's slides from IJCAI 2013. The original link now returns a broken, cut-off file, so this is an archived copy.</li>\n</ul>\n<h4 id=\"commerce-trading-and-games\">Commerce, trading and games</h4>\n<p><strong>Design a stock exchange (like NASDAQ or Binance).</strong></p>\n<ul>\n<li>What makes it hard: orders must be matched in a strict, fair order with very low latency, every trade must be recorded exactly once, and the matching engine is hard to split across machines because every order for one stock touches the same order book.</li>\n<li>Chapters: <a href=\"/learn/design-payment-system\">Design a payment system</a> for idempotency and ledgers, <a href=\"/learn/distributed-transactions\">Distributed transactions</a>, <a href=\"/learn/reliability-patterns\">Reliability patterns</a>, <a href=\"/learn/performance-and-latency\">Performance and latency</a>.</li>\n<li>References: <a href=\"https://www.youtube.com/watch?v=b1e4t2k2KJY\" target=\"_blank\" rel=\"noopener noreferrer\">How to Build an Exchange</a>, a talk on Jane Street's YouTube channel. <a href=\"https://www.around25.com/blog/building-a-trading-engine-for-a-crypto-exchange\" target=\"_blank\" rel=\"noopener noreferrer\">Building a trading engine for a crypto exchange</a>, Cosmin Harangus's 2018 walkthrough in Go. <a href=\"https://bhomnick.net/building-a-simple-limit-order-in-go/\" target=\"_blank\" rel=\"noopener noreferrer\">Building an exchange limit order book in Go</a>, Ben Homnick's 2017 post on order book data structures that add and cancel orders in about constant time.</li>\n</ul>\n<p><strong>Design an online multiplayer card game.</strong></p>\n<ul>\n<li>What makes it hard: every player must see the same game state, players may be on slow or dropped connections, and the server has to stop players from cheating. Turn-based games can be asynchronous, while fast games need real-time updates.</li>\n<li>Chapters: <a href=\"/learn/realtime\">Real-time communication</a>, <a href=\"/learn/ood-deck-of-cards\">Design a deck of cards</a>, <a href=\"/learn/design-gaming-leaderboard\">Design a real-time gaming leaderboard</a>.</li>\n<li>References: <a href=\"https://web.archive.org/web/20180929181117/http://www.indieflashblog.com/how-to-create-an-asynchronous-multiplayer-game.html\" target=\"_blank\" rel=\"noopener noreferrer\">How to Create an Asynchronous Multiplayer Game</a>, an Indie Flash Blog post (archived copy). <a href=\"http://buildnewgames.com/real-time-multiplayer/\" target=\"_blank\" rel=\"noopener noreferrer\">Real Time Multiplayer in HTML5</a>, Sven Bergström's article on keeping fast browser games in sync.</li>\n</ul>\n<h4 id=\"infrastructure-and-building-blocks\">Infrastructure and building blocks</h4>\n<p><strong>Design a tinyurl system like Bitly.</strong></p>\n<ul>\n<li>What makes it hard: short codes must never collide, redirects must be very fast, and billions of links need a sharding plan.</li>\n<li>Chapters: <a href=\"/learn/design-url-shortener\">Design a URL shortener</a>, <a href=\"/learn/design-pastebin\">Design a text-sharing service like Pastebin</a>, <a href=\"/learn/unique-ids\">Unique IDs</a>.</li>\n<li>References: <a href=\"https://n00tc0d3r.blogspot.com/2013/09/big-data-tinyurl.html\" target=\"_blank\" rel=\"noopener noreferrer\">System Design for Big Data: tinyurl</a>, a 2013 post on the N00tc0d3r blog.</li>\n</ul>\n<p><strong>Design a random ID generation system.</strong></p>\n<ul>\n<li>What makes it hard: many servers must hand out IDs without talking to each other on every request, the IDs must never repeat, and they often need to sort roughly by time.</li>\n<li>Chapters: <a href=\"/learn/unique-ids\">Unique IDs</a>, <a href=\"/learn/consensus\">Consensus</a>.</li>\n<li>References: <a href=\"https://blog.x.com/engineering/en_us/a/2010/announcing-snowflake\" target=\"_blank\" rel=\"noopener noreferrer\">Announcing Snowflake</a>, Twitter's 2010 post on the service it built to generate tweet IDs. <a href=\"https://github.com/twitter-archive/snowflake\" target=\"_blank\" rel=\"noopener noreferrer\">twitter-archive/snowflake</a>, the archived code.</li>\n</ul>\n<p><strong>Design an API rate limiter.</strong></p>\n<ul>\n<li>What makes it hard: limits must hold across many servers, so the counters live somewhere shared, and checking them must add almost no latency. You also decide what happens to a request over the limit and how to treat bursts.</li>\n<li>Chapters: <a href=\"/learn/rate-limiting\">Rate limiting</a>, <a href=\"/learn/reverse-proxy-and-api-gateway\">Reverse proxies and API gateways</a>, <a href=\"/learn/reliability-patterns\">Reliability patterns</a>.</li>\n<li>References: <a href=\"https://stripe.com/blog/rate-limiters\" target=\"_blank\" rel=\"noopener noreferrer\">Scaling your API with rate limiters</a>, Paul Tarjan's 2017 Stripe post on its four kinds of limiters and load shedders, built on token buckets in Redis.</li>\n</ul>\n<h4 id=\"newer-questions-to-try\">Newer questions to try</h4>\n<p>These questions come up often in interviews today. They have no references here, but each is close to a worked design, so you can check most of your answer against it.</p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n<div class=\"table-wrap\"><table><thead><tr><th>Question</th><th>What makes it hard</th><th>Chapters that help</th></tr></thead><tbody><tr><td>Design a ride-hailing service's driver matching</td><td>Finding nearby drivers among millions of moving points, updated every few seconds.</td><td><a href=\"/learn/realtime\">Real-time communication</a>, <a href=\"/learn/nosql-databases\">NoSQL databases</a>, <a href=\"/learn/design-notification-system\">Design a notification system</a></td></tr><tr><td>Design a ticket booking system for a big concert</td><td>Selling each seat exactly once while a huge crowd arrives in the same minute.</td><td><a href=\"/learn/distributed-transactions\">Distributed transactions</a>, <a href=\"/learn/rate-limiting\">Rate limiting</a>, <a href=\"/learn/design-payment-system\">Design a payment system</a></td></tr><tr><td>Design a distributed job scheduler</td><td>Running each job once and on time, even when the machine that was going to run it fails.</td><td><a href=\"/learn/queues-and-async\">Queues and async work</a>, <a href=\"/learn/consensus\">Consensus</a>, <a href=\"/learn/reliability-patterns\">Reliability patterns</a></td></tr><tr><td>Design a metrics and monitoring system</td><td>Storing a flood of small time-stamped numbers cheaply and answering queries over them quickly.</td><td><a href=\"/learn/observability\">Observability</a>, <a href=\"/learn/event-streaming\">Event streaming</a>, <a href=\"/learn/nosql-databases\">NoSQL databases</a></td></tr><tr><td>Design a distributed message queue</td><td>Keeping messages durable and in order while many producers and consumers come and go.</td><td><a href=\"/learn/queues-and-async\">Queues and async work</a>, <a href=\"/learn/event-streaming\">Event streaming</a>, <a href=\"/learn/consensus\">Consensus</a></td></tr><tr><td>Design an ad click counter</td><td>Counting billions of clicks accurately enough to bill for them, without counting any click twice.</td><td><a href=\"/learn/event-streaming\">Event streaming</a>, <a href=\"/learn/batch-processing\">Batch processing</a>, <a href=\"/learn/design-sales-rank\">Design Amazon's sales rank by category</a></td></tr></tbody></table></div>","headings":[{"id":"more-system-design-questions","title":"More system design questions","depth":3},{"id":"storage-caching-and-file-systems","title":"Storage, caching and file systems","depth":4},{"id":"social-messaging-and-collaboration","title":"Social, messaging and collaboration","depth":4},{"id":"search-ranking-and-recommendations","title":"Search, ranking and recommendations","depth":4},{"id":"commerce-trading-and-games","title":"Commerce, trading and games","depth":4},{"id":"infrastructure-and-building-blocks","title":"Infrastructure and building blocks","depth":4},{"id":"newer-questions-to-try","title":"Newer questions to try","depth":4}]},{"id":"more-object-oriented-design-questions","title":"More object-oriented design questions","html":"<h3 id=\"more-object-oriented-design-questions\">More object-oriented design questions</h3>\n<p>In an object-oriented design question you design the classes, their fields and methods, and how they work together, for a program that runs on one machine. Start by listing the nouns in the problem (they become classes) and the verbs (they become methods). Then write the main methods in code.</p>\n<p><strong>Design a circular array.</strong></p>\n<p>A circular array is a fixed-size array whose end wraps around to its start. Picture a queue of the last 1,000 log lines: when line 1,001 arrives, it overwrites line 1 instead of growing the array.</p>\n<ul>\n<li>Hint: store the items in a plain list plus a <code>start</code> offset. The item at logical position <code>i</code> lives at index <code>(start + i) % capacity</code>. Rotating the array by <code>k</code> then means only changing <code>start</code>, which takes constant time instead of moving every item. Decide what <code>append</code> does when the array is full (overwrite the oldest item, raise an error or grow), make the class iterable in logical order, and test the wrap-around at the end of the list.</li>\n<li>Closest worked chapter: <a href=\"/learn/ood-hash-table\">Design a hash map</a>, which also maps positions into a fixed-size array with <code>%</code> and has to decide what to do when it fills up.</li>\n</ul>\n<p>The questions below are common in interviews. They aren't worked through in the handbook, so use the hint and the closest chapter to check your approach.</p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n<div class=\"table-wrap\"><table><thead><tr><th>Question</th><th>Hint</th><th>Closest worked chapter</th></tr></thead><tbody><tr><td>Design an elevator system</td><td>Separate the elevator car (its floor, direction and stops) from the controller that decides which car answers each call.</td><td><a href=\"/learn/ood-call-center\">Design a call center</a>, which also assigns incoming requests to whoever is free</td></tr><tr><td>Design a vending machine</td><td>Model the machine as a set of states (idle, has money, dispensing) with the allowed moves between them.</td><td><a href=\"/learn/ood-parking-lot\">Design a parking lot</a></td></tr><tr><td>Design a library management system</td><td>Books, copies of a book, members and loans are separate classes. A loan links one copy to one member with a due date.</td><td><a href=\"/learn/ood-parking-lot\">Design a parking lot</a>, where spots, vehicles and levels play similar roles</td></tr><tr><td>Design a movie ticket booking system</td><td>Two people must not book the same seat. Hold seats for a few minutes while someone pays, then release them.</td><td><a href=\"/learn/ood-parking-lot\">Design a parking lot</a></td></tr><tr><td>Design a chess game</td><td>A <code>Piece</code> base class with one subclass per piece type, each knowing its own legal moves. The board checks the rules that involve several pieces.</td><td><a href=\"/learn/ood-deck-of-cards\">Design a deck of cards</a>, which uses the same base-class-and-subclass pattern</td></tr><tr><td>Design an in-memory file system</td><td>Files and directories share a base class, and a directory holds children, which can be either. Paths are walked one name at a time.</td><td><a href=\"/learn/ood-hash-table\">Design a hash map</a>, for looking up children by name</td></tr><tr><td>Design a text editor with undo and redo</td><td>Store each edit as an object that knows how to apply and reverse itself, and keep two stacks of them.</td><td><a href=\"/learn/ood-lru-cache\">Design an LRU cache</a>, for another design built from two cooperating data structures</td></tr></tbody></table></div>","headings":[{"id":"more-object-oriented-design-questions","title":"More object-oriented design questions","depth":3}]},{"id":"how-to-practise-with-these","title":"How to practise with these","html":"<h3 id=\"how-to-practise-with-these\">How to practise with these</h3>\n<p>A short plan you can keep up for a few weeks:</p>\n<ol>\n<li><strong>One question a day.</strong> Pick a worked design first, answer it on your own with a 45-minute timer, then read the chapter. Once you've done a few, move on to the questions without worked answers.</li>\n<li><strong>Then try the variation.</strong> After the URL shortener, try Pastebin. After the chat system, try Facebook chat. Most of the reasoning carries over, and the differences show you what matters in each.</li>\n<li><strong>Revisit your weak spots.</strong> If your estimates were off, spend a day on <a href=\"/learn/estimation\">estimation</a>. If you couldn't scale the database, read <a href=\"/learn/relational-databases\">relational databases</a> and <a href=\"/learn/nosql-databases\">NoSQL databases</a> again.</li>\n</ol>\n<p>After each attempt, review your answer against this checklist:</p>\n<ul>\n<li>Did I ask about use cases and scale before drawing anything?</li>\n<li>Did I write down my estimates (requests per second, storage, read-to-write ratio) and use them later?</li>\n<li>Did I give each component in my high-level design a reason to exist?</li>\n<li>Did I go deep on the two or three parts that matter most for this question?</li>\n<li>Did I name at least one bottleneck and fix it, and say what the fix costs?</li>\n<li>Did I discuss what happens when a server, a database or a data center fails?</li>\n<li>Did I compare at least two options for one important decision and say why I picked one?</li>\n</ul>\n<p><strong>Practising with a partner</strong> is closer to the real thing than practising alone. One person plays the interviewer and keeps the question vague at first, so the other has to ask. The interviewer answers questions about scale with numbers, pushes on one component (\"what happens if this cache goes down?\"), and keeps time. Afterwards, go through the checklist together, then swap roles. Playing the interviewer teaches you a lot too, because you see which answers are easy to follow.</p>\n<h3 id=\"further-reading\">Further reading</h3>\n<p>If you only read a few of the references above, start with these. Each one explains a decision you'll face again and again.</p>\n<ul>\n<li><a href=\"https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf\" target=\"_blank\" rel=\"noopener noreferrer\">Dynamo: Amazon's Highly Available Key-value Store</a>: the 2007 paper that introduced many of the ideas in the distributed key-value store design.</li>\n<li><a href=\"http://infolab.stanford.edu/~backrub/google.html\" target=\"_blank\" rel=\"noopener noreferrer\">The Anatomy of a Large-Scale Hypertextual Web Search Engine</a>: Brin and Page's description of the first Google, covering crawling, indexing and ranking.</li>\n<li><a href=\"https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/nishtala\" target=\"_blank\" rel=\"noopener noreferrer\">Scaling Memcache at Facebook</a>: how a simple cache becomes a large shared system, from NSDI 2013.</li>\n<li><a href=\"https://highscalability.com/how-google-serves-data-from-multiple-datacenters/\" target=\"_blank\" rel=\"noopener noreferrer\">How Google Serves Data from Multiple Datacenters</a>: a clear comparison of the ways to copy data between sites and what each costs.</li>\n<li><a href=\"https://stripe.com/blog/rate-limiters\" target=\"_blank\" rel=\"noopener noreferrer\">Scaling your API with rate limiters</a>: a short, practical post on protecting an API from too much traffic.</li>\n<li><a href=\"/learn/real-world-architectures\">Real-world architectures</a>: the handbook's list of articles on how real systems are built.</li>\n</ul>","headings":[{"id":"how-to-practise-with-these","title":"How to practise with these","depth":3},{"id":"further-reading","title":"Further reading","depth":3}]}]}