The path through a senior system design loop. 46

Forty-five minutes, an open-ended prompt, and an interviewer waiting. The candidates who do well are not the ones who know more — they are the ones running 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. Not arithmetic for its own sake — the numbers are what turn 'we'll add a cache' into 'we need 40 GB of cache, which 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 in between. Then the four ways a server pushes to a client — polling, long-poll, SSE, WebSocket — and what each costs at a million connections.

Resources, verbs, and status codes are the easy half. The half that shows seniority: which verbs are safe to retry, how to paginate a list that is changing underneath you, and how to version without breaking clients.

Cache-aside, read-through, write-through — and the three questions each one answers differently: who fills it, who invalidates it, and what happens the moment 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.

Two different problems that get discussed as one. Replication is copies of the same data; partitioning is different data on different machines. Almost every scaling story is one, the other, or both at once.

CAP is the most misquoted theorem in interviews. What the P actually means, why 'CA' is not a choice you get to make, and the spectrum between linearizable and eventual that the theorem never mentions.

Everything remote fails, and the ambiguous failure — you sent it, you never heard back — is the one that generates real incidents. Timeouts, backoff, jitter, and the retry that quietly doubles a charge.

Metrics, logs, traces — what each one is actually for, why averages hide every interesting outage, and what an SLO commits you to once it is written down.

"Put a load balancer in front of it" is the easy part. Which layer it operates at, which algorithm it picks a backend with, and how it knows a backend is actually healthy decide whether it helps or hides an outage.

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: the protocol, its failure modes, the blocking flaw every interviewer probes, and when 2PC is the right answer versus when to use a saga instead.

When data outgrows one machine it must split across many. Naive modulo hashing reshuffles almost everything when a node is added or removed. Consistent hashing moves only the keys that must move.

A replicated system needs one ordered history despite crashes and delayed messages. Raft explains how terms, majority elections, log replication, and commit rules create that safety — then follows 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.

Hardcoding a backend's IP works until that backend is 40 instances behind an autoscaler. Discovery is how one service finds another; a mesh is what happens once every service needs the same discovery, retry, and security logic.

"Find everything near this point" is a query a B-tree can't answer efficiently — location is two dimensions and a B-tree sorts on one. Every geospatial index is a different answer to the same collapsing problem.

Every system eventually loses a datacenter, a cloud region, or a whole AZ. Multi-region design doesn't answer 'can we survive it' — it answers 'how much data do we lose, and how long are we down,' made concrete as RPO and RTO.

Some questions don't need an exact answer, just a fast 'definitely not' — a bloom filter trades a small, tunable false-positive rate for 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.

A CDN is caching-basics applied at continental scale, with one new problem caching-basics never faces: invalidating a copy you don't operate, sitting in a datacenter you don't control.

Two ideas that show up together so often they get treated as one: split reads from writes, and stop storing current state — store the events that produced it.

Same data, two processing models with opposite failure modes: batch trades latency for simplicity, streaming trades simplicity for the ability to answer "what's happening right now."

Once you have more than a couple of services, every one needs auth, rate limiting, and routing — a gateway is the decision to build that once, at the edge, instead of five times, inconsistently.

Networking Basics covers which transport to pick. This is what happens after you've picked WebSockets and have a million of them open: routing a message, surviving a deploy, not letting one restart become an outage.

cron works fine on one box. The moment a scheduled job runs across N boxes, 'run this every hour' becomes a distributed-systems problem: what fires the trigger, who owns the lease, and what happens when the box that was supposed to run it is mid-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 — keep a hot slice of data close and fast, accept some staleness. The hard part is everything that goes wrong at scale: cold start, cache stampede, hot keys, eviction under pressure.

A B-tree answers 'find rows where column equals X.' Full-text search answers a different question — 'find documents containing these words, ranked by relevance' — and needs a structure built for it from the ground up: 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. The baseline is table stakes; the substance lies in the follow-ups: hot keys, cache invalidation, OLTP/OLAP separation, and CAP trade-offs under write pressure.

A chat system looks trivial until you see the hard parts: millions of persistent connections, presence that is always slightly wrong, ordering that must hold per-conversation across multiple devices, and 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, equities. Orders pour in; the engine maintains a price-time priority book and matches each incoming order against the best opposite side.

'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.

Crawling the web at scale is a graph traversal problem wearing a systems-design costume: a URL frontier that never runs out, politeness limits per domain, dedup at billion-URL scale, and a robots.txt rule that changes the crawl's shape entirely.

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

Two people typing in the same document at the same instant is a conflict that can't wait for a lock — the edit has to land immediately and the document has to converge anyway. Operational transforms and CRDTs are two different answers to that same constraint.