The path through a senior system design loop. 50

You get forty-five minutes, an open prompt, and an interviewer who waits. Strong candidates do not know more. They follow a sequence: requirements, estimation, API, data model, high level, then one deep dive.

Vertical until it hurts, then horizontal. What statelessness actually buys you, why load balancer choice changes failure behavior, and the point where adding machines stops helping.

QPS, storage, bandwidth. The arithmetic has a purpose. The numbers turn 'we'll add a cache' into 'we need 40 GB of cache, and it fits on one box'.

ACID as four separate promises, not a slogan. What a transaction actually holds, what each isolation level lets through, and why an index is the difference between a scan and a seek.

DNS, TCP, HTTP, and the load balancer between them. Then the four ways a server pushes to a client: polling, long-poll, SSE, and WebSocket. Each one has a cost at a million connections.

Resources, verbs, and status codes are the easy half. The other half shows seniority. Which verbs are safe to retry? How do you paginate a list that changes while you read it? How do you version without breaking clients?

Cache-aside, read-through, and write-through each answer three questions differently. Who fills the cache? Who invalidates it? What happens when it is empty?

Why 'we'll put it on a queue' is the start of the conversation. At-least-once versus at-most-once, what ordering a queue does and does not give you, and where dead letters go.

People often discuss these two problems as one. Replication puts copies of the same data on many machines. Partitioning puts different data on different machines. Almost every scaling story uses one, the other, or both.

CAP is the most misquoted theorem in interviews. Learn what the P means and why 'CA' is not a real choice. Then learn the range between linearizable and eventual, which the theorem never mentions.

Every remote call can fail. The ambiguous failure causes real incidents: you sent the request and never got a reply. Timeouts, backoff, jitter, and the retry that charges a card twice.

Metrics, logs, and traces each have a different job. Averages hide every interesting outage. A written SLO is a promise, and this note shows what it commits you to.

"Put a load balancer in front of it" is the easy part. Three choices decide if it helps or hides an outage: its layer, its algorithm, and how it checks that a backend is healthy.

Networks lose responses. Clients retry. Without protection, that retry charges the card twice. Learn the protocol every payments engineer must know cold.

Atomic commits across distributed participants. Learn the protocol, its failure modes, and the blocking flaw that every interviewer probes. Then learn when to use 2PC and when to use a saga.

When data outgrows one machine, it must split across many. Naive modulo hashing moves almost every key when you add or remove a node. Consistent hashing moves only the keys that must move.

A replicated system needs one ordered history despite crashes and delayed messages. Raft uses terms, majority elections, log replication, and commit rules to make that safe. This note then covers the operational edge cases.

"Add an index" is the correct answer to almost every slow-query question and the wrong answer to almost every write-path question. Both facts come from the same structure.

"The write returned success" and "the write survives a crash a millisecond later" are two different claims. A WAL is the mechanism that makes the second one true without a full disk sync on every operation.

A hardcoded backend IP works until that backend is 40 instances behind an autoscaler. Discovery is how one service finds another. A mesh puts the same discovery, retry, and security logic in front of every service.

"Find everything near this point" is a query a B-tree cannot answer efficiently. Location has two dimensions, and a B-tree sorts on one. Each geospatial index is a different way to fold two dimensions into one.

Every system eventually loses a datacenter, a cloud region, or a whole AZ. Multi-region design does not ask 'can we survive it'. It asks how much data we lose and how long we are down. RPO and RTO put numbers on those two questions.

Some questions need only a fast 'definitely not'. A bloom filter accepts a small, tunable false-positive rate. In return, it gives O(1) membership checks that never touch disk. HyperLogLog and count-min sketch make the same trade for counting.

When one local transaction cannot cover a multi-service payment flow, a saga coordinates committed steps, reliable events, compensation, and forward recovery.

'Only one worker may run this at a time' sounds trivial until the worker is one of many processes on different machines. Single-active-worker and leader election appear in every payments and fraud system.

Every API gateway must answer one question within its latency budget: has this caller used up its quota? Counting accurately across nodes, through clock skew and traffic spikes, is the real problem.

Retries alone make a struggling downstream worse, not better. Circuit breakers stop calling it, bulkheads stop one slow dependency from starving every other request, and backpressure makes overload visible instead of silent.

One system, many customers, and each must feel like the only one. Whose data can a bug leak, whose traffic can slow a neighbour, and whose upgrade can break someone else.

Nobody can explain a balance column that you update in place. A ledger records every movement of money as an immutable entry. You can rebuild any balance, audit it, and check it against the bank's records.

A CDN applies caching basics at continental scale. It adds one new problem: you must invalidate a copy that you do not operate, in a datacenter that you do not control.

These two ideas occur together so often that people treat them as one. Split reads from writes. Store the events that produced the current state, not the state itself.

Same data, two processing models, opposite failure modes. Batch gives up latency to stay simple. Streaming gives up simplicity to answer "what is happening right now."

With more than a few services, each one needs auth, rate limiting, and routing. A gateway builds that once, at the edge. Without it, you build it five times, each one a bit different.

Networking Basics covers which transport to pick. This note starts after you pick WebSockets and have a million open. Route a message, survive a deploy, and stop one restart from becoming an outage.

cron works fine on one box. On N boxes, 'run this every hour' becomes a distributed-systems problem. What fires the trigger? Who owns the lease? What happens when the box that owns the job is in the middle of a deploy?

Almost every durability and ordering guarantee Kafka makes reduces to one primitive: a partition is a log, replicated to a few brokers, with one leader. This note builds from that up through production failure modes.

A cache is a bet. You keep a hot slice of data close and fast, and you accept some staleness. The hard part is what goes wrong at scale: cold start, cache stampede, hot keys, and eviction under pressure.

A B-tree answers 'find rows where column equals X.' Full-text search answers a different question: 'find documents that contain these words, ranked by relevance.' That question needs its own structure, the inverted index.

S3 promises eleven nines of durability for objects with no schema and no query language. Object storage is what a filesystem looks like once you throw out POSIX and design for scale, durability, and cost first.

Cassandra and DynamoDB answer scale differently than a relational database: give up joins and ad-hoc queries, get linear write scalability and tunable consistency instead. The trade only makes sense once you see the LSM tree and the gossip ring underneath it.

The 'design bit.ly' question. Everyone gets the baseline. The real test is in the follow-ups: hot keys, cache invalidation, OLTP/OLAP separation, and CAP trade-offs under write pressure.

A chat system looks simple until you see the hard parts. Millions of persistent connections. Presence that is always slightly wrong. Per-conversation ordering across many devices. Reconnect storms.

Design a large-scale notification pipeline: fan-out architecture, queueing, provider delivery, token lifecycle, cancellation, and the failure modes an interviewer is likely to probe.

The core of every exchange: FX, crypto, and equities. Orders arrive fast. The engine keeps a price-time priority book and matches each new order against the best opposite side.

Two people click the same seat in the same millisecond. One must lose, and neither may be charged for a seat they do not get. The same problem sits under concert tickets, hotel rooms, flights, and limited-stock drops.

A rider taps a button, and a nearby driver gets an offer within seconds. Underneath is a live map of moving drivers, matching done in batches, and a price that must clear the market block by block.

'Design Twitter's home feed' is really a fan-out question: precompute each follower's feed on every post (fan-out-on-write) or assemble it at read time (fan-out-on-read)? Every real feed is a hybrid, and the celebrity account is the reason why.

A web crawler is a graph traversal problem in a systems-design costume. You need a URL frontier that never runs out, politeness limits per domain, and dedup at billion-URL scale. One robots.txt rule can change the whole crawl.

Uploading a video is the easy 5% of the problem. The other 95% has three parts. A transcoding pipeline turns one file into a dozen bitrate and codec variants. A CDN serves the right chunk to a phone on bad wifi. A player never lets the viewer see a stall.

Two people type in the same document at the same instant. A lock is too slow. Each edit must apply immediately, and the document must still converge. Operational transforms and CRDTs are two answers to that problem.