The path through a senior system design loop. 25

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.

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.

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.

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.

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.