System Design Primer · llms.txt

The System Design Primer

Donne Martin's The System Design Primer (CC BY 4.0), the guide to designing large-scale systems, reorganized into 35 chapters: core trade-offs, building blocks from DNS to databases, and worked system design and object-oriented design interview questions. Also 16 extra chapters written for this site on topics the primer doesn't cover, such as rate limiting, consistent hashing and consensus.

Start here

Why system design matters, how much to study, and how to run an interview answer.

Core trade-offs

The tensions every design balances: speed, scale, availability and consistency.

  • Performance vs scalability: A service is scalable if it results in increased performance in a manner proportional to resources added. Generally, increasing performance means serving more units of work, but…
  • Latency vs throughput: Latency is the time to perform some action or to produce some result.
  • Availability vs consistency: In a distributed computer system, you can only support two of the following guarantees:
  • Consistency patterns: With multiple copies of the same data, we are faced with options on how to synchronize them so clients have a consistent view of the data. Recall the definition of consistency…
  • Availability patterns: There are two complementary patterns to support high availability: fail-over and replication.

Building blocks

The components a request passes through, from DNS to the database.

  • Domain name system: A Domain Name System (DNS) translates a domain name such as www.example.com to an IP address.
  • Content delivery network: A content delivery network (CDN) is a globally distributed network of proxy servers, serving content from locations closer to the user. Generally, static files such as…
  • Load balancer: Load balancers distribute incoming client requests to computing resources such as application servers and databases. In each case, the load balancer returns the response from the…
  • Reverse proxy (web server): A reverse proxy is a web server that centralizes internal services and provides unified interfaces to the public. Requests from clients are forwarded to a server that can fulfill…
  • Application layer: Separating out the web layer from the application layer (also known as platform layer) allows you to scale and configure both layers independently. Adding a new API results in…
  • Database: A relational database like SQL is a collection of data items organized in tables.
  • Cache: Caching improves page load times and can reduce the load on your servers and databases. In this model, the dispatcher will first lookup if the request has been made before and try…
  • Asynchronism: Asynchronous workflows help reduce request times for expensive operations that would otherwise be performed in-line. They can also help by doing time-consuming work in advance,…
  • Communication: HTTP is a method for encoding and transporting data between a client and a server. It is a request/response protocol: clients issue requests and servers issue responses with…
  • Security: This section could use some updates. Consider contributing!

Reference

Numbers to memorise, more practice questions, and real-world architectures.

  • Appendix: You'll sometimes be asked to do 'back-of-the-envelope' estimates. For example, you might need to determine how long it will take to generate 100 image thumbnails from disk or how…

System design questions

Worked solutions with use cases, constraints, diagrams and scaling discussion.

Object-oriented design questions

Class design exercises with Python solutions.

Beyond the primer: concepts

Topics the primer leaves out, from estimation to consensus. Written for this site.

  • Back-of-the-envelope estimation: Before you draw boxes, you need a rough idea of how big the problem is. Is it 50 requests per second or 500,000? Gigabytes or petabytes? The answer decides whether one database…
  • Consistent hashing: Once data or cache entries are spread across several machines, every request has to answer one question: which machine holds this key? The obvious answer, hashing the key and…
  • Rate limiting: A rate limiter caps how many requests a client can make in a period of time and turns away the rest. It protects shared capacity from one noisy client, blunts abuse like…
  • Unique ID generation: Every row, message, order and event needs an identifier. On a single database you let it hand out auto-increment numbers and never think about it again. Once you shard, run…
  • Message queues and event streams: The primer's Asynchronism chapter explains why queues exist: put slow work on a queue and let workers pick it up later. Interviewers then ask the next questions. What happens if a…
  • Timeouts, retries and idempotency: Once a request crosses a network, three outcomes are possible: it succeeds, it fails, or you don't know. The third case is the hard one. The server may never have received the…
  • Distributed transactions and sagas: Inside one relational database, a transaction makes several writes succeed or fail together. The primer's RDBMS section lists the ACID properties that make this work. Split the…
  • Consensus, leader election and coordination: Many designs quietly assume that some decision is made exactly once: which database node is the primary, which worker owns a shard, who holds a lock, whether a config change…
  • Real-time updates: polling, WebSockets and server-sent events: Plain HTTP is request/response: the client asks, the server answers, and the server has no way to speak first. Plenty of features need the server to speak first. Examples include…
  • Monitoring, logging and tracing: A system you can't see into is a system you can't run. When checkout gets slow at 2 a.m., someone needs to answer three questions fast: is it actually broken for users, where is…

Beyond the primer: design questions

More worked interview questions, written for this site.

  • Design a distributed key-value store: The primer describes a key-value store as a hash table: put a key, get it back. This question asks you to build one that spans dozens of machines, keeps working when some of them…
  • Design a notification system: Almost every product sends notifications: a one-time login code, "your order shipped", "your friend commented", "presale starts in an hour". Each one is a small message, but the…
  • Design a chat system: A chat system lets people exchange short messages in near real time, one to one or in groups, across several devices each. It looks simple until you list what users take for…
  • Design search autocomplete (typeahead): Autocomplete suggests whole queries while you type a prefix: type "how to bo" and you see "how to boil eggs", "how to boost wifi signal" and a few more. It saves keystrokes,…
  • Design a video streaming platform: A video platform lets creators upload videos and lets viewers watch them on anything from a phone on a train to a living-room TV. The upload side is a batch pipeline that turns…
  • Design a file sync service (like Dropbox or Google Drive): A file sync service keeps a folder identical across a user's laptop, desktop and phone, and across everyone it's shared with. Save a file on one machine and, a few seconds later,…

About the primer

The flashcard decks, topics still being written, credits, contributing and the license.

  • About the primer: The provided Anki flashcard decks use spaced repetition to help you retain key system design concepts.