Home › Learn

The learning path

43 chapters in 5 tracks, from the request path to whole systems.

Foundations

How a request travels through a system, how to run a design interview, how load is spread and shed, and how timeouts, retries and queues keep it standing. After it you can size a service from its numbers, talk through a design in an interview's order, and defend its timeouts, retries, queues and limits.

• The Request Path: Clients, app servers and databases, and how to read latency.
• Scaling Out: Capacity, queues, load balancers, and finding the next bottleneck.
• Back-of-the-Envelope Estimation: From users to requests per second, peaks and headroom, storage over the years, the latency numbers to know, and sizing a design for what it costs.
• The Design Interview: Run a 45-minute system design interview: requirements, estimates, API, high-level design, deep dives, and stating every tradeoff. Learn it now and use it on every chapter after.
• Balancing Load: Round robin, least connections and consistent hashing, and when each one fits.
• Timeouts and Retries: When to give up, when to try again, retrying writes safely, circuit breakers, and how retries turn a rush into an outage.
• Idempotency: Why a retried write can be applied twice, idempotency keys, how the timeout changes the repeats, idempotent operations, and what exactly once really means.
• Latency Budgets: Fan-out, why the tail grows with every call, and deadlines for the parts a page can do without.
• Load Shedding: Serve what you can, well, when traffic outgrows the servers: queues, goodput and turning requests away early.
• Rate Limiting: Per-caller limits: token buckets, fixed and sliding windows, 429s, limits across many machines, and how they differ from load shedding.
• Queues and Workers: Move slow work out of the request: queues, workers, backlog, retries, at-least-once delivery, and pub/sub and logs for events with many consumers.
• Circuit breakers: Stop calling a service that is failing, give it time to recover, and test it with a few probe calls before opening up again.

Caching and edge

Answer requests without asking the database, and from close to the user. After it you can place a cache and a CDN, and say how stale each copy may get.

• Caching: Hit rates, skewed traffic, and keeping cached data fresh.
• Choosing a TTL: Writes the cache can't see, what a TTL promises, what it costs the database, and stampedes when popular copies expire.
• Sizing a Cache: Working sets, eviction, why each extra hit costs more than the last, and when cache memory beats database capacity.
• The Edge: Distance, CDNs, and the freshness versus speed dial.

Data

Copies of data, what a database can run out of besides CPU, indexes and data models, where files belong, keeping writes safe when machines fail, and finding what broke. After it you can choose between replicas, a cache and object storage, explain failover, durability and connection limits, and read a failing system's metrics.

• Replication: Read replicas, replication lag, and reading your own writes.
• Bandwidth: Responses have a size: how large ones fill a server's network, hold back small ones, and what buys more bandwidth.
• Connection Limits: Work out how many connections a database needs, and why slow queries run out of them before the CPU runs out.
• Indexes: Scans against index lookups, why an index only helps queries on its column, and the price every index charges on every write.
• Data Modeling: SQL or NoSQL, by what it costs: access patterns first, normalised tables and joins, keys shaped per query, copying and embedding, and what each copy costs to keep in step.
• Cache or Replicas: Choose between a cache and read replicas from the shape of the traffic, what's fresh enough, and the price.
• Object Storage: Give large files a home of their own: object storage, links instead of proxies, and what every request and byte costs.
• Availability: Nines, SLOs, single points of failure, health checks, database failover, and how availability adds up across a design.
• Durability: What "saved" means: flushing to disk, the write-ahead log, synchronous and asynchronous commit and replication, backups, RPO and RTO.
• Observability: Percentiles instead of averages, the four golden signals, error budgets and burn rate, and finding the cause from what each component reports.

Data at scale

Unique IDs, splitting data across machines, how fresh a read must be, quorums, hot keys, transactions, and events: fan-out, pub/sub, streams and real-time connections. After it you can partition data, pick consistency per read, handle hot keys and transactions, and choose between a queue, a topic and a stream.

• Unique IDs: Counters, ranges, UUIDs, Snowflake IDs and hashes: minting unique codes on many servers at once, and how long each one is.
• Partitioning: Key-value stores, partitions and how keys are spread across them, moving data when partitions are added, and why one hot key still lands on one machine.
• Consistency: Strong, eventual and read-your-writes reads, quorums, CAP and PACELC, and choosing a promise for each kind of data.
• Quorums: Replicas, and the quorum rule R + W > N: what it guarantees, what one failed replica does to each setting, the latency of waiting for more copies, and how consensus picks a leader.
• Hot Keys: One record that takes the traffic: row locks, split counters, numbers that change every few milliseconds, and the celebrity problem in feeds.
• Transactions and isolation: Lost updates, isolation levels, and the three ways to run a read-modify-write: no protection, a row lock, or an optimistic check, and what a hot row does to each.
• Fan-out: Building a feed when it's read or when it's posted, what pushing costs per follower, why one star account breaks it, and mixing push and pull.
• Pub/sub: Sending one event to several subscribers, how a slow one only hurts itself, sizing each for its own deadline, topics versus logs, and what each subscriber must cope with.
• Streams: A log that remembers: partitions and the parallelism they allow, order per key and the hot key, failed messages holding a line, retention, and replay.
• Real-time connections: Holding connections open: polling against long polling and WebSockets, a connection as a slot, handshakes and the reconnect storm, heartbeats, and several gateways.

Case studies

Whole systems designed the way an interview asks: requirements, numbers, design, deep dives and tradeoffs. After it you can run a design interview end to end on a system you haven't seen.

• URL Shortener: Design and build ink.ly end to end: requirements and numbers, unique codes, fresh reads after an edit, redirects fast worldwide, and what happens when each box fails.
• News Feed: Designing Inkwell Home end to end: requirements, estimates, API, pull against push against a hybrid, the celebrity problem, deep dives and tradeoffs.
• Notifications: Designing Inkwell Notify end to end: urgent and bulk, the numbers, one queue or two, failed and slow sends, deep dives and tradeoffs.
• Payments: Designing Inkwell Pay end to end: what must never happen, the numbers, a ledger that survives a crash, retrying through a failover, deep dives and tradeoffs.
• File Sharing: Designing Inkwell Drive end to end: sizes first, the numbers, metadata apart from blobs, presigned uploads, a CDN, deep dives and tradeoffs.
• Reactions: Designing Inkwell Reactions end to end: a count that may lag but not lose a like, the numbers, one hot key, combining writes, deep dives and tradeoffs.
• Chat: Designing Inkwell Chat end to end: held connections, an ordered stream per conversation, huge groups, a delivery outage, and several gateways.