Interview prep

Everything for the system-design interview in one place: the method you run in the room, the design forks you'll be asked to pick between, and the interview rooms themselves — a full design interview over a live document, one call at a time.

Method & drills

the repeatable spine

methodThe HLD FrameworkThe repeatable spine for any design interview: clarify requirements, estimate, API, data model, high-level design, deep-dive, name the bottleneck.Read ~13 min methodNon-Functional RequirementsPicking the targets that drive every later choice: latency SLO, availability nines, consistency, durability, and scale — and the cost of each.Read ~13 min drillBack-of-the-Envelope EstimationTurn a vague product into a handful of numbers: users to requests per second to storage, bandwidth and cache size, rounded to one significant figure and said out loud.Run the drill methodDriving the InterviewThe communication and judgment an interviewer actually scores: clarifying questions, stated assumptions, time-boxing, and answering 'scale it 10×'.Read ~13 min

Design forks

which tool? the either/or calls

design forkB-Tree vs LSM TreeThe storage-engine decision: update in place, or append and merge?Read ~13 min design forkSQL vs NoSQLThe database-family decision: a relational schema with joins and transactions, or a store shaped to one access pattern that scales out?Read ~13 min design forkPush vs Pull (Fan-out)Build every timeline when the post is written, or assemble it when it's read? Fan-out on write vs fan-out on read, decided by the read/write ratio and fan-out skew.Read ~13 min design forkSync vs Async (When to Add a Queue)Answer the request now, or accept it and do the work later? The trade between an immediate result and decoupling, spike absorption, and failure isolation.Read ~13 min design forkMonolith vs MicroservicesOne deployable or many? In-process simplicity and easy transactions vs independent deploy, scale, and team autonomy at the cost of network calls and operational load.Read ~13 min design forkWhen to Cache (and When Not To)A cache trades staleness and complexity for speed — when is that trade worth it? Read/write ratio, hit ratio, and staleness tolerance decide.Read ~13 min

Interview rooms

a full interview, one call at a time

interview roomDesign a Rate LimiterThe canonical warm-up: keep one global counter correct and fast across a fleet. The race two servers run over the last token is the whole problem — the algorithm is a detail next to it.Predict ~1.5 h · Read ~35 min interview roomDesign a URL ShortenerA full interview over a live design document — commit to each call, watch the consequence get computed, and carry the procedure out of the room.Predict ~1.5 h · Read ~45 min interview roomDesign a Chat SystemWhatsApp/Messenger as one routing fabric you operate — hold two hundred million connections, find the recipient, fan out to a huge group, and survive a server dying.Predict ~1.5 h · Read ~55 min interview roomDesign a News FeedTwitter/X, decided by one fork — build every timeline when the post is written, or when it is read. Fifty reads per write says precompute, until one account with fifty million followers says otherwise.Predict ~1.5 h · Read ~45 min interview roomDesign a Notification SystemOne event, one buzz — from parts that are each unreliable. The event arrives at-least-once and every channel gateway is a best-effort black box, so effectively-once delivery gets built at the edges: an outbox, an idempotency key, backoff, and backpressure.Predict ~1.5 h · Read ~50 min interview roomDesign a Ride-Sharing ServiceUber/Lyft, decided by one firehose: a million driver locations a second, each stale in four. That write rate forces the design — live location lives in memory, non-durable, and “who's nearby” becomes a spatial-index query, not a scan. Matching is the easy part.Predict ~1.5 h · Read ~50 min interview roomDesign a Web CrawlerCommon Crawl scale, decided by one queue: a colossal fetch rate that has to stay gentle on every host. A flat queue cannot be polite, so the frontier gains structure — one back queue per host, a heap that knows who is due — and “have I fetched this URL?” becomes a Bloom filter, far smaller than the raw strings.Predict ~1.5 h · Read ~50 min interview roomDesign a Video Streaming ServiceYouTube/Netflix, decided by one wall: the same video served to a huge audience is terabits per second of egress, while storing the whole library is only tens of terabytes. That flips the design outward — a CDN edge tier of caches near the viewer, a client-pull ABR ladder, and an async transcode pipeline behind a durable blob store.Predict ~1.5 h · Read ~50 min interview roomDesign a Distributed CacheRedis/Memcached at fleet scale, decided by one wall: a single wildly popular key hashes to one shard, and no shard count spreads it. So the hot key gets hot-shard replication and an app-local near cache, while a consistent-hash ring, invalidate-on-commit, LFU eviction, and leases keep the hit ratio high. Storing key-value pairs fast is the easy part.Predict ~1.5 h · Read ~50 min interview roomDesign a Metrics & Monitoring SystemPrometheus/Datadog scale, decided by one wall: ingesting the firehose is a shardable append, but keeping every raw sample at fleet cardinality for years is a petabyte-a-year cost no disk buys down. So cardinality control bounds the label dimension and a rollup pipeline tiers data by age, while a hot tier and a bounded query engine keep reads fast and safe. Swallowing the firehose is the easy part.Predict ~1.5 h · Read ~50 min interview roomDesign a Distributed Job SchedulerCron/Airflow at scale, decided by one wall: accepting and running a task are both cheap, but finding which of hundreds of millions of pending tasks are due each instant is impossible to poll for. So a durable time-bucketed index fronted by a timing wheel makes “what's due now” a cheap pop, sharded to survive a node loss, while lease-and-ack dispatch and an idempotency key run each due task once even across worker crashes. Finding what's due is the hard part.Predict ~1.5 h · Read ~50 min interview roomDesign an Ad Click AggregatorAd-tech firehose scale, decided by one fork: counting clicks is a windowed sum, but a dashboard needs a fast number and billing needs an exact one, and at ten thousand clicks a second those two cannot come from one path. So every click is appended to a durable log, a stream aggregator serves a fast provisional count, and a batch job replays the log to recompute the exact billable count and override it, while a windowed dedup set counts each click once. Counting is the easy part.Predict ~1.5 h · Read ~50 min