System design reading list

System design interviews are being taught less like trivia quizzes and more like whiteboard problem-solving drills built around a few repeatable case studies. (github.com) One of the biggest public study hubs is the open-source System Design Primer on GitHub, which had about 343,000 stars and 55,400 forks when it was crawled this month. Its README says the project is a “continually updated” collection for learning large-scale systems and preparing for interview questions with diagrams and sample solutions. (github.com) The social posts that circulated this week packaged that same idea into a tighter reading list: study a finite set of real systems, then practice explaining trade-offs out loud. The examples named in the posts included Apache Kafka, Uber’s estimated-time-of-arrival stack, and Google Docs-style collaborative editing. (x.com) A system-design interview is usually a conversation about how to build a product under limits like latency, scale, and reliability, not a test of whether a candidate can recite vendor names. The Primer’s interview section tells candidates to practice common design questions and compare their own diagrams and decisions against worked solutions. (github.com) That explains why coaches keep pushing requirements first. In the second post, the advice was to actively draw out requirements and define the application programming interface, or API, before diving into databases, queues, or caches. (x.com) The case studies in the reading list work because each one anchors an abstract concept in a concrete product problem. Uber’s 2022 DeepETA post says ETA predictions affect fares, pickup times, rider-driver matching, and deliveries, and that the production system combines a road-network model with machine learning trained on historical and real-time signals. (uber.com) Uber’s earlier routing-engine write-up makes the same lesson easier to see: the map is modeled as a graph, intersections become nodes, road segments become edges, and the company had to rebuild its ETA engine as it expanded into more cities and products. That turns a common interview prompt — “design Uber” — into a set of specific trade-offs around routing, cold starts, and latency. (uber.com) Google Docs is useful for a different reason. Google researcher Neil Fraser’s 2009 paper on Differential Synchronization describes a way to keep multiple copies of a document converged by exchanging small changes, which is the core problem behind collaborative editing. (research.google) Kafka fills the messaging side of the curriculum. Uber said in an April 2026 engineering post on disaster recovery that it built uReplicator to copy Apache Kafka data across regions with a “zero-data-loss guarantee,” a concrete example of the durability and failover questions that show up in senior interviews. (uber.com) The through line in all three examples is narrower than “learn every tool.” Candidates are being told to practice a small number of designs with explicit constraints, then explain why one choice improves latency, cost, or correctness and what it breaks somewhere else. (x.com) That is why the reading-list posts spread so quickly: they offered a bounded syllabus for a part of software hiring that often feels open-ended. The promise was not that 26 links can replace experience, but that a candidate can walk into an interview with a sharper mental model of how real systems are sketched, scoped, and defended. (x.com)