Open-ended design rounds broken into the building blocks they draw on, plus full case studies worked end to end with explicit trade-off reasoning.
70 published across 12 topics.
Requirements gathering, capacity estimation, and structuring the first ten minutes of a design round.
Clarifying questions stop helping at the first one whose answer would not change what you draw. Past that point you are moving risk onto the interviewer, not reducing it. Turn every remaining question into a stated assumption, draw a first diagram, and ask the rest against that diagram.
A pragmatic guide to dismantling component teams, breaking database monoliths, and surviving the political fallout of organizational restructuring. Use this engineering leadership answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects org design to the point an interviewer is testing.
Spend roughly three minutes agreeing the functional scope, three pinning the numbers that change the architecture, and four turning those numbers into a derived estimate of request rate, storage and bandwidth — then state which design decision each number forces.
A cynical engineering leader's framework for categorizing technical debt, quantifying business risk, and negotiating with product managers. Use this engineering leadership answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects tech debt to the point an interviewer is testing.
Nines only mean something as a downtime budget over a stated window, and dependencies in series multiply: five hard dependencies at three nines each put your own ceiling near 99.4 percent, so the target is met by removing dependencies from the critical path rather than by asking each owner for more nines.
Horizontal versus vertical scaling, load-balancer strategies, and stateless service design.
Presence at 10 million users is a lease system, not a connection-state table. Clients renew short-lived keys, the dot expires when renewals stop, and the real cost is bounded fan-out to visible watchers rather than every contact.
Reactive scaling has a latency of its own — metric window, evaluation, provisioning, warm-up, health checks — and a surge that arrives faster than that latency is served entirely by the capacity you already had. The fix is a scheduled floor plus a saturation-based signal, not a more aggressive policy.
Multi-tenant placement at scale should use measured resource cost, not tenant count. Keep the long tail in shared pools, move heavy tenants to reserved or dedicated capacity, and design tenant migration as a normal operation because every placement decision ages quickly.
Thumbnail generation system design should return one displayable image immediately while every durable variant is produced asynchronously. Persist the original, write metadata, show a client-side preview or first small thumbnail, and expose variant readiness so the UI never asks for an image size that is not ready.
Scale up while one machine can still hold the workload, because it costs no distributed complexity; scale out once you need redundancy or exceed the largest instance. Scaling out only works if the tier is stateless, which means externalising session state rather than pinning users to a node.
Cache placement, eviction, invalidation, and the stampede and coherence failure modes.
A cache stampede happens when one hot key expires and every concurrent miss rebuilds the same value. Let one request rebuild while the rest wait or serve stale, then prevent repeats with stale-while-revalidate, jittered TTLs and refresh-before-expiry. Use this caching answer to show the decision, trade-off, and evidence rather than a memorised definition.
A cynical look at global cache invalidation, the necessity of origin shielding, and why relying on manual purges is an architectural anti-pattern. Use this distributed systems answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects caching to the point an interviewer is testing.
Pick a write policy that matches your consistency requirement rather than treating invalidation as an afterthought, then defend against the three failure modes that only appear under load: stampede on expiry, staleness from lost invalidation messages, and unbounded growth from missing eviction.
The key must contain every request input that changes the response — identity, scope, locale, device class, active flags — because anything left out silently merges two different responses into one entry. An unkeyed input is both a correctness bug and an injection surface.
Choose the layer by who else can reuse the same bytes and how tolerable staleness is that far from the user, then size it from the working set rather than the dataset. Watch the miss rate, not the hit rate: origin load is proportional to misses, so 99 percent falling to 95 is a fivefold traffic increase.
Choosing a store, sharding and partitioning, replication topologies, and storage-engine trade-offs.
Replication propagates the deletion, so recovery depends on point-in-time restore from a base backup plus the write-ahead log, and the hard part is not the restore but extracting one tenant's rows from a shared store while the rest of the system keeps serving traffic.
A geospatial index for nearby drivers reduces latitude and longitude to ordered cells such as geohash, S2 or H3. Query the rider's cell plus neighbours, keep the hot current-position index in memory because positions churn, and filter candidates by true distance afterwards.
A direct-to-storage upload keeps API servers off the byte path. The API issues short-lived scoped credentials and records a pending row; the client uploads multipart parts to object storage, and a storage event or reconciliation job marks the file ready. It also connects presigned urls to the point an interviewer is testing.
Choose the store from the dominant access pattern and the invariants it must enforce, not from a category label. Choose the shard key so the most frequent query is answerable from one shard, the key has enough distinct high-traffic values to spread load, and shards can be split later without rewriting every row.
Put the equality predicates first in a composite index and the ordering column last, so one index serves the filter, the sort and the limit. Every index is a write tax, and whether that tax is a random in-place page update or a sequential append is the difference between a B-tree engine and an LSM engine.
A hot partition from one account cannot be fixed by ordinary rebalancing because it is one key. Split the key into write-sharded sub-keys or aggregate writes before storage; both choices move cost to reads, ordering, rollups or approximation.
Photo storage should separate originals from thumbnails. Originals are large, rarely read and irreplaceable, so keep a canonical erasure-coded object; thumbnails are small, hot and rebuildable, so replicate them, cache them at the edge and address them by content or transform version.
An uncompromising examination of split-brain resolution, quorum consensus, fencing tokens, and why timestamp-based last-write-wins is fundamentally flawed. Use this distributed systems answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects databases to the point an interviewer is testing.
CAP and PACELC in practice, consistency models, consensus, and what you give up under partition.
The write committed on the primary and the reload was served by a replica that had not applied it yet. Fixing it means giving that session a read-your-writes guarantee, either by routing its reads to the primary for a bounded window or by carrying the commit position and refusing to read a replica behind it.
Accepting writes on both sides means conflicts are inevitable, so the design choice is who resolves them. Last-write-wins discards an edit by clock accident; version vectors detect the conflict and hand it back; CRDTs merge deterministically but only for the operations they model. Use this conflict resolution answer to show the decision, trade-off, and evidence rather than a memorised definition.
Under partition you either reject requests on the side that cannot reach a quorum, or serve them and accept divergent replicas that need reconciling. CAP's C is linearisability, not ACID's C, and the choice binds only while partitioned.
Queues versus logs, delivery guarantees, ordering, backpressure, and exactly-once claims.
A Kafka-style consumer down for an hour has missed an offset range, not necessarily lost data. If retention still covers the gap, it resumes from the committed offset; catch-up needs surplus throughput, idempotent handlers, event-time logic and a plan for retention expiry. Use this event driven answer to show the decision, trade-off, and evidence rather than a memorised definition.
A job queue backlog should be classified into expired jobs, superseded jobs and still-required jobs. Drain the last fully; shed expired work with a record and collapse superseded work by key. Deadlines and collapse keys must be written at enqueue time. It also connects backpressure to the point an interviewer is testing.
An analysis of the architectural reality of exactly-once guarantees in Flink, from distributed snapshots to two-phase commits. Use this data engineering answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects streaming to the point an interviewer is testing.
The server holds one row per message, partitioned by conversation and clustered by descending sequence so a page is a contiguous read, and clients page by keyset cursor rather than offset. Per-user state moves to a side table so the body stays shared, and if messages are end-to-end encrypted the wipe is a key-custody question, not a storage one.
An architectural examination of Dead Letter Queues, atomic offset management, and schema enforcement in high-throughput Kafka consumers. Use this distributed systems answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects KAFKA to the point an interviewer is testing.
A queue distributes work and forgets each message once acknowledged; a log is a retained, partitioned, replayable record that many consumers read independently at their own offsets. Use this message queues answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects event log to the point an interviewer is testing.
Every producer must have a declared answer — block, buffer to a bounded local store, or drop — chosen per event class rather than once for the whole fleet, because the default of blocking on a full in-memory buffer turns a broker outage into an outage of every service that publishes to it.
Chat ordering with offline clients separates ephemeral typing indicators from durable messages. Messages need a server-assigned per-conversation sequence and a client-generated id for deduplication, so reconnecting phones replay outboxes without duplicates.
Resource modelling, pagination, idempotency, versioning, and backward compatibility.
Treat errors as published contract: an HTTP status that classifies the failure, a stable machine-readable code the client branches on, a human message that carries no internal detail, per-field detail for validation, and an explicit statement of whether a retry is safe.
Model resources around client workflows, paginate with an opaque keyset cursor because offset pagination skips and duplicates rows under concurrent writes, make unsafe operations replayable with a client-supplied idempotency key, and evolve additively so that versioning stays a last resort rather than a routine.
Accept the request, return 202 with the location of an operation resource, and do the work behind a queue. Clients poll that resource or receive a signed callback, and either way the operation id is the contract - one that a callback can reach before the submitter has finished recording it.
An idempotency key for retried charges is minted by the client per payment intent, claimed under a unique constraint in the same transaction as the charge, and used to replay the stored response on repeat. The API contract must define retention, in-flight retries and mismatched request bodies.
Throttling algorithms, circuit breakers, retries with jitter, bulkheads, and graceful degradation.
Rate limiting an LLM gateway by request count fails because cost is tokens, and output tokens are unknown at admission. Budget tokens per tenant, reserve input plus expected output, settle against reported usage when the stream ends, cap concurrent streams, and cancel upstream on disconnect.
Redis gives twenty gateways one counter mutated atomically through INCR or a Lua script, so rate limiting is fleet-wide. What breaks first is usually latency, not throughput: a slow Redis stalls every request for its timeout. Hot keys, caller clocks inside scripts and counts lost on async failover follow.
A global limit protects the service from overload but says nothing about how capacity is divided, so one tenant can consume most of it while staying under the ceiling. Fairness needs per-tenant accounting: a token bucket for the steady-state contract, a concurrency limit so expensive requests cannot hog workers, and round-robin queueing so a burst queues behind itself.
No retry policy or circuit breaker helps here, because the change was valid and the defect was already deployed. What bounds the damage is treating configuration as a rollout with stages and bake time, a kill switch whose own dependencies cannot fail with it, and a measured rollback time.
Analyzing architectural resilience patterns, including circuit breakers, bulkheads, adaptive load shedding, and the mitigation of retry storms. Use this distributed systems answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects resilience to the point an interviewer is testing.
Global rate limiting fails when each region owns a local counter, because five regions each allowing 100 requests creates a 500-request ceiling. Use one atomic shared counter, route each user to an owning region, or lease regional budget deliberately. It also connects distributed counters to the point an interviewer is testing.
Fixed windows permit twice the limit across a boundary; the two sliding windows fix that at a memory or an accuracy cost; token bucket permits a bounded burst and leaky bucket smooths output instead. Across a fleet the counter must sit in one store mutated atomically, or each node silently enforces its own limit.
Inverted indexes, relevance scoring, and the ingestion-to-query pipeline of a search product.
Polite web crawler system design starts with per-host queues, crawl-delay enforcement and URL normalisation. The crawler partitions by host so one worker owns the next-allowed fetch time, uses a durable seen set with a Bloom filter in front, and keeps freshness work separate from first-time discovery.
An inverted index maps terms to posting lists, built by an analysis chain that must run identically over documents and queries, ranked by BM25 plus business signals, and fed by a change stream of denormalised documents with reindexing behind an alias treated as routine.
Offline you need graded relevance judgements and a rank-aware metric to compare orderings; online you need an experiment sensitive enough to detect the effect, with click data corrected for the fact that position drives clicks on its own, and a guardrail on zero-result and abandonment rates.
Metrics, logs, traces, cardinality control, and designing systems that can be debugged live.
Every distinct combination of label values is a separate time series with its own index entry, so an unbounded label multiplies series count by the number of users rather than adding one dimension. Metrics are the wrong tool for per-entity questions: keep labels bounded, move per-user debugging to exemplar-linked traces, and guard against the next unbounded label.
A green dashboard and a dead pipeline look identical, so absence of data has to be an alerting condition in its own right: heartbeats that fire when they stop arriving, an alerting path that does not share infrastructure with production, and at least one signal produced outside the system being measured. It also connects monitoring pipeline to the point an interviewer is testing.
Metrics tell you something is wrong and when it started, traces tell you which hop owns the latency, logs tell you what happened to one request. Cardinality is what makes metrics expensive, sampling is what makes traces affordable, and the goal is answering new questions from data already held.
An architectural blueprint for unified observability pipelines, focusing on edge processing, intelligent tail-based sampling, and vendor-agnostic telemetry.
Tenant isolation, secrets management, defence in depth, and threat modelling a distributed system.
Treat it as a confirmed breach until proven otherwise: preserve logs, scope who saw what, and start the disclosure clock alongside the investigation. The cause is almost always tenant scoping living in application code, where one forgotten filter leaks everything - so move enforcement below the code, to row-level security.
The damage is fixed before the leak by three earlier decisions: whether the token can be revoked and how fast that takes effect, how narrowly it was scoped, and whether your audit trail can attribute actions to that specific credential rather than only to the tenant.
Envelope encryption at scale separates Data Encryption Keys (DEKs) from Key Encryption Keys (KEKs), caches plaintext DEKs only inside strict boundaries, and designs rotation so latency, KMS limits, and algorithm migration do not break availability.
Isolation runs from a tenant_id column through separate schemas and databases to a stack per tenant, trading efficiency against blast radius. Careful filtering is not an isolation model: push the predicate below the application with row-level security and scope caches and object prefixes too.
Complete designs worked end to end: URL shortener, news feed, chat, ride-hailing, and more.
Evaluate feature flags in an SDK from a cached ruleset, assign users by hashing a per-experiment salt with the user id so assignment is sticky, log exposure where the arms first diverge, gate readouts on an automated SRM check, and make the kill switch a top-precedence rule that works with the control plane down.
A notification system at 50 million a day is sized by bursts and provider limits, not its average of about 580 a second. Accept with an idempotency key, apply preferences once, fan out to per-channel queues with transactional and bulk lanes, rate-limit each provider, and never fail over blindly on a timeout.
A distributed job scheduler cannot promise exactly-once execution when workers die mid-job, so it promises at-least-once with idempotent jobs. Materialise each firing as a run row, claim it with a lease and heartbeats, judge time by one clock, and key side effects on job id plus scheduled time.
In file sync, the file itself does not travel. Changed content-hashed chunks go to a block store, then a small metadata commit names the version it replaced. Other laptops pull the new manifest and the chunks they lack. A concurrent edit fails that commit and becomes a conflicted copy, never a silent overwrite.
Video streaming startup time is won before playback: transcode into an adaptive ladder, cut aligned segments, package a manifest, and cache the first low-bitrate segment near the viewer. At play time the system can only afford manifest fetch, licence check, first segment and decoder start. It also connects adaptive bitrate to the point an interviewer is testing.
Size it first: 200M daily actives opening the feed six times a day is 42k reads/s at peak, while 100M posts fanned out to 200 followers each is 231k feed writes/s, so writes dominate. Push to ordinary accounts, pull for high-follower ones, and store ids so deletes and blocks filter on read.
Clarify scale first, then size it: 100M new links a day at a 100:1 read ratio gives roughly 1.2k writes/s and 116k redirects/s, needing 7-character base62 keys. Generate keys from leased counter blocks scrambled by a bijection, serve reads from cache and CDN, and redirect with 302 rather than 301.
Ride matching system design should rank drivers by estimated pickup time and market impact, not straight-line distance. Offer the ride under a short soft lock, use a small batching window when it improves assignment quality, and keep the rider wait within a few seconds. Use this dispatch answer to show the decision, trade-off, and evidence rather than a memorised definition.
An authoritative breakdown of horizontal matchmaking services, constraint relaxation algorithms, and distributed locking for ticket-based lobbies. Use this matchmaking answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects SBMM to the point an interviewer is testing.
CDN caching for global reads works when cacheable bytes are separated from personalised fragments. Use content-addressed assets, tag-based purges for pages that must change, and plan for purge storms because invalidation sends cold traffic back to the one origin region. It also connects http caching to the point an interviewer is testing.
Paid video streaming DRM raises the cost of copying rather than making copying impossible. Start with signed short-lived URLs, add encrypted segments, and use DRM when keys must stay outside application code, while budgeting for licence latency and unsupported devices.
Real-time pricing system design should publish numbered price versions instead of calculating a different answer per request. Compute prices by region and time window, serve the current version consistently, and freeze quotes briefly so users are not surprised during checkout.
Selling a specific seat is a uniqueness problem, not a throughput one, so the seat row is the serialisation point and the design lives or dies on the reservation hold: a short expiring claim written atomically, plus a queue in front so the contention never reaches the database at full force.
Preventing double booking seats means claiming the seat before payment, not racing two payments and reconciling later. A short atomic hold serialises buyers, payment only starts for the winner, and uncertain payment outcomes are settled by reconciliation rather than silent expiry.