Every system is the same five boxes.
The interview is about the wires.

There are exactly two kinds of design interview, and confusing them is the most common way strong candidates lose rounds.

Part I (F) is the vocabulary — you cannot design what you cannot name. Part II (H) is twenty worked HLD case studies. Part III (L) is object-oriented design with complete Java. Part IV (X) is interview craft: mock transcripts, scripts, drills, and a study plan.

Suggested path if you have four weeks

1. Week 1 — F1 → F10. Do the estimation drills until QPS math is automatic.
2. Week 2 — F11 → F19, then H1 → H6. One case study per day, out loud, on paper, timed to 45 minutes.
3. Week 3 — L1 → L8 (patterns + concurrency), then L9 → L14 typed from scratch without looking.
4. Week 4 — H7 → H20, X1 → X8, and re-do the two case studies you did worst on.

The question "Design YouTube" is deliberately unanswerable as stated. Your first job is not to answer it — it is to convert an ambiguous prompt into a bounded engineering problem. Interviewers score that conversion heavily. Here is the four-phase structure, with the minutes you should spend in a 45-minute round.

Phase 1 — Scope & requirements (5–8 min)

Ask questions until you can write down a numbered list. Three categories, always in this order:

• Functional requirements — what a user can do. Keep it to 3–5 verbs. "Upload a video, watch a video, search videos." Explicitly park the rest: "I'll treat comments, monetisation, and recommendations as out of scope unless you want them."
• Non-functional requirements — the properties that decide the architecture. Availability target, latency target, consistency requirement, durability, read:write ratio, scale.
• Scale numbers — DAU, requests/sec, object sizes, retention. Ask for them; if the interviewer says "you tell me," pick round numbers and say them out loud.

Phase 2 — Estimation & API/data contract (5–8 min)

Do the back-of-envelope math (F2). Then write the API surface — 3–6 endpoints is plenty — and the core entities with their key fields. Doing this before drawing boxes prevents the classic failure of designing infrastructure that cannot express the product.

Phase 3 — High-level design, then deep dives (20–25 min)

Draw the simplest thing that satisfies the requirements — usually client → LB → service → DB. Walk one read path and one write path end to end, out loud. Only then start scaling it, and scale it because a number forces you to, not because caching is a reflex.

The interviewer will then pick one or two components and say "go deeper." Common deep dives: the sharding key, the cache invalidation strategy, how the queue guarantees delivery, how you handle a hot partition, what happens when a node dies mid-write.

Phase 4 — Bottlenecks, failure, wrap-up (5 min)

Volunteer the weaknesses before you are asked. "The single point of failure here is X; I'd fix it with Y. The thing I'd monitor first is Z. If traffic grew 10×, the first component to break is the metadata DB, and the fix is to shard on userId."

What the interviewer is actually filling in on the scorecard

The point of estimation is not arithmetic. It is to answer one question: does this fit on one machine? If yes, do not distribute it. If no, the numbers tell you which dimension broke first — CPU, memory, disk, or network — and that dimension dictates the architecture.

Numbers you must know cold

Three consequences you should be able to state instantly: memory is ~100× faster than SSD, SSD is ~20× faster than spinning disk, and a cross-continent round trip costs more than 300 in-datacenter round trips. That last one is why you put a CDN in front of anything a global audience reads, and why chatty microservice calls across regions are an anti-pattern.

Powers of two, and the only conversions you need

The estimation recipe

Always four quantities, in this order. Round aggressively — 86,400 becomes 100,000, and nobody objects.

1. QPS = DAU × actions-per-user-per-day ÷ 100,000. Then peak QPS = 2–3 × average (state which multiplier you're using).
2. Storage = writes/day × bytes/write × retention days × replication factor.
3. Bandwidth = QPS × bytes/request, split into ingress and egress.
4. Memory for cache = apply the 80/20 rule — cache the 20% of data serving 80% of reads, for a hot window (often 1 day).

Worked example — Twitter-scale

Reference capacities of one machine

What actually happens when a user hits your URL

DNS as a design tool

DNS is not just name resolution — it is your first load balancer and your disaster-recovery switch.

• Round-robin DNS — multiple A records; free, dumb, no health awareness, and clients cache aggressively.
• GeoDNS / latency-based routing — return the IP of the nearest healthy region. This is how you get users to the right datacenter.
• Failover via TTL — a 60-second TTL means a regional outage can be rerouted in about a minute. Long TTLs (24 h) are cheaper but pin you during incidents. State the trade-off in interviews: low TTL = fast failover, more DNS queries; high TTL = fewer queries, slow recovery.
• Anycast — one IP announced from many locations; BGP routes the user to the topologically nearest. Used by CDNs and public resolvers.

TCP vs UDP, and when the answer is genuinely UDP

QUIC / HTTP-3 is the interesting modern answer: it rebuilds reliability and ordering on top of UDP, per-stream, which removes TCP's head-of-line blocking and folds the transport + TLS handshake into a single round trip. Also it survives IP changes (phone switching Wi-Fi → cellular) because connections are identified by a connection ID, not the 4-tuple. That is a genuinely strong thing to mention in a mobile-heavy design.

HTTP versions — what changed and why you care

Idempotency and HTTP methods

Safe = no side effects (GET, HEAD). Idempotent = doing it twice equals doing it once (GET, PUT, DELETE — not POST). This matters because retries are mandatory in distributed systems, and retrying a non-idempotent POST double-charges a customer. The fix is an idempotency key: the client generates a UUID, sends it as a header, and the server stores (key → result) so a replay returns the original response instead of re-executing. Stripe's API is the canonical example; say so.

CDN — the highest-leverage box on the diagram

A CDN is a globally distributed reverse-proxy cache. It reduces latency (content is physically closer), reduces origin load (cache hit ratio of 90%+ is normal), and absorbs traffic spikes and some DDoS.

• Push CDN — you upload content to the edge proactively. Good for small, rarely-changing catalogues.
• Pull CDN — the edge fetches from origin on first miss and caches per TTL. The default for almost everything.
• Cache key — usually the URL. Beware of caching a personalised response under a shared key; use Vary headers or put user-specific content on a separate, uncached path.
• Invalidation — either purge by URL/tag (slow, rate-limited) or never invalidate: use content-hashed filenames (app.9f3c2a.js) with a one-year TTL. The second option is strictly better and is what every serious frontend build does.
• Signed URLs — time-limited tokens so private media can still be served from the edge. This is how YouTube/Netflix serve authenticated video without the origin touching the bytes.

Request/response styles

Server-to-client push — the four options

The rule: if the client only needs to receive, use SSE — it is far simpler operationally. If both sides send frequently, use WebSocket. If you only need updates every 30+ seconds, polling is fine and you should say so rather than reflexively reaching for sockets.

The hard part of WebSockets is not the protocol, it's the state

A WebSocket pins a user to one specific server. That breaks the "stateless service" assumption everything else relies on, and creates four problems you must be ready to discuss:

1. Routing — to send a message to user B, you must know which gateway node holds B's connection. Solution: a session registry (Redis: userId → nodeId, with TTL and heartbeat).
2. Delivery across nodes — node A must hand the message to node B. Solution: a pub/sub bus (Redis Pub/Sub, Kafka, or NATS) with a topic per node or per user.
3. Load balancing — connections are long-lived, so a new node gets zero traffic after a scale-out. You need connection draining and sometimes forced rebalancing.
4. Deploys — every deploy drops every connection. Clients need reconnect with exponential backoff and jitter, or you get a thundering herd that takes down the freshly deployed cluster.

Vertical vs horizontal

Vertical (bigger machine) is underrated: it is free of distributed-systems complexity, and modern cloud instances go to hundreds of cores and terabytes of RAM. It fails on two counts — there is a ceiling, and one machine is a single point of failure. Horizontal (more machines) has no ceiling and gives you redundancy, but every problem you had becomes a distributed problem: coordination, consistency, partial failure.

Statelessness is the enabling property

A stateless service stores nothing about a client between requests, so any node can serve any request, and you can add or kill nodes freely. State does not disappear — you relocate it: session data to Redis or a signed cookie/JWT, uploaded files to blob storage, in-flight jobs to a queue.

Load balancers: L4 vs L7

Real architectures use both: an L4 layer (or Anycast) absorbs raw connections and DDoS, then hands to an L7 layer that does routing and TLS.

Balancing algorithms — and the one that is usually right

• Round robin — even distribution, ignores that request cost varies wildly.
• Weighted round robin — for heterogeneous hardware.
• Least connections — good proxy for load when request durations vary.
• Least response time — best general-purpose choice; adapts to a degraded node automatically.
• IP hash / consistent hash — sends the same client (or key) to the same node; used for cache locality, not for fairness.
• Power of two choices — pick two nodes at random, send to the less loaded one. Nearly as good as global least-connections but needs no global state, so it scales to huge fleets. Mentioning this is a genuine depth signal.

Scaling the whole picture, in the order you should propose it

"SQL or NoSQL?" is the wrong question

The right question is what is my access pattern, and what does the storage engine make cheap? Answer these five and the database chooses itself:

1. Do I query by a single key, or do I need flexible ad-hoc queries and joins?
2. Is the write volume beyond what one node can take?
3. Do I need multi-object atomic transactions?
4. Is the schema stable, or genuinely heterogeneous per record?
5. Do I need range scans / sorting, or only point lookups?

Indexes: the single highest-value DB topic

An index is a separate data structure that maps a column value to row locations, so a lookup becomes O(log n) instead of O(n). The cost is that every write must update every index — indexes make reads faster and writes slower, and consume disk.

B+ tree (Postgres, MySQL/InnoDB — the read-optimised default)

LSM tree (Cassandra, RocksDB, LevelDB — the write-optimised default)

Index types you should be able to name

• Clustered index — the table itself is stored in index order (InnoDB primary key). One per table; range scans on it are extremely fast. A random UUID primary key destroys this by causing page splits everywhere — use an ordered ID (see H3, Snowflake) or UUIDv7.
• Secondary (non-clustered) index — maps value → primary key, so a lookup costs two traversals unless the index is covering.
• Composite index — (a, b, c) serves queries on a, (a,b), (a,b,c) — the leftmost-prefix rule — but not on b alone. This is one of the most-asked DB interview questions.
• Covering index — includes all columns the query needs, so the engine never touches the heap. The single best query optimisation available.
• Hash index — O(1) equality only, no ranges.
• Bitmap index — low-cardinality columns in analytics stores.
• Inverted index — token → list of documents. The basis of search (F14).
• Geospatial — R-tree, quadtree, geohash, S2 cells (see H12).

ACID, precisely

• Atomicity — all operations in the transaction happen, or none do. Implemented with a write-ahead log and rollback.
• Consistency — the database moves from one valid state to another, respecting constraints. This is largely the application's responsibility; it is the weakest letter and the one people over-explain.
• Isolation — concurrent transactions do not corrupt each other. The interesting letter.
• Durability — once committed, it survives a crash. Implemented by fsync-ing the WAL, and in distributed systems by replicating to a quorum before acknowledging.

Isolation levels and the anomalies they prevent

*InnoDB's Repeatable Read prevents most phantoms using next-key (gap) locks; Postgres's Repeatable Read is snapshot isolation and prevents phantoms for reads but allows write skew.

Pessimistic vs optimistic concurrency

Note the escape hatch: after N attempts you must fail loudly, not loop forever. Unbounded retries under contention are how a hot SKU takes down a checkout service.

Deadlocks

Four Coffman conditions must all hold: mutual exclusion, hold-and-wait, no preemption, circular wait. Databases usually detect cycles and kill a victim transaction, returning a retryable error. The practical prevention is lock ordering: always acquire locks on rows in a deterministic order (e.g. ascending primary key), so a cycle cannot form. In a money-transfer design, say: "I lock the two accounts in ascending account-id order" — it is a one-line answer that shows you have debugged this in real life.

These are the two orthogonal axes of distributing data, and mixing them up is a common mistake. Replication = the same data on multiple nodes (for availability and read throughput). Partitioning/sharding = different data on different nodes (for write throughput and total capacity). Real systems do both: shard the data, replicate each shard.

Replication topologies

Synchronous vs asynchronous replication

Sync: the leader waits for the follower to acknowledge before confirming the write. No data loss on leader failure, but a slow follower slows every write, and if it dies, writes stall. Async: the leader confirms immediately. Fast and available, but a leader crash loses the un-replicated tail. Semi-sync (wait for exactly one follower) is the practical middle ground and what most production MySQL/Postgres setups use.

Failover, and why it is dangerous

• Detect — usually a timeout on heartbeats. Too short → spurious failovers; too long → extended downtime.
• Elect — a consensus algorithm (Raft) or an external coordinator (ZooKeeper/etcd) picks the most up-to-date follower.
• Reconfigure — clients and remaining followers must learn the new leader.
• Split-brain — the old leader may still think it is the leader and accept writes. Prevented by fencing tokens: every leadership term gets a monotonically increasing number, and storage rejects writes carrying an old token.

Partitioning strategies

Choosing a shard key — the highest-stakes decision in the design

A good shard key has three properties: high cardinality (many distinct values), even distribution (no value dominates), and query alignment (your most common query can be answered from a single shard). You will usually be asked to defend it.

Resharding without downtime

1. Double-write to old and new topology while backfilling historical data.
2. Verify by comparing reads from both (shadow reads, diff the results, alert on mismatch).
3. Flip reads to the new topology behind a feature flag, per-tenant if possible.
4. Stop double-writing; decommission the old shards after a safety window.

Alternatively, pre-shard: create 1,024 logical partitions on day one and map many of them onto few physical nodes. Growing then means moving whole logical partitions — no key remapping at all. This is what Vitess, Citus, and most mature systems do, and proposing it unprompted is a strong signal.

The problem it solves

The ring

Where it shows up

• Distributed caches (Memcached clients, Redis Cluster uses 16,384 fixed hash slots — a pre-sharding variant of the same idea).
• Dynamo-style databases: Cassandra, DynamoDB, Riak, ScyllaDB.
• Sharded WebSocket gateways and rate limiters (route a user consistently to the node holding their counter).
• Load balancers doing cache-affinity routing (consistent hashing upstream mode in Nginx/Envoy).

CAP, stated correctly

The common phrasing "pick two of three" is wrong and interviewers notice. Network partitions are not a choice — on a real network they will happen. So the theorem really says: when a partition occurs, you must choose between consistency and availability. When there is no partition, you can have both.

• CP — during a partition, refuse to serve requests that cannot be made consistent. Examples: ZooKeeper, etcd, HBase, Spanner, MongoDB (with majority writes). Choose for balances, inventory, locks, leader election.
• AP — during a partition, keep serving, accept divergence, reconcile later. Examples: Cassandra, DynamoDB, Riak, DNS. Choose for feeds, likes, product catalogues, session stores, metrics.

Consistency models, strongest to weakest

Note that the middle four are session guarantees: they are per-user promises, not global ones, which makes them cheap. Most products need "eventual consistency plus read-your-writes," and being able to say precisely that — rather than "strong" or "eventual" — is the mark of someone who has shipped.

Quorums

When a read returns conflicting versions, the system must reconcile: last-write-wins (simple, silently loses data, needs synchronised clocks), version vectors (detect concurrent writes and hand both to the application — Riak's siblings), or CRDTs (data types whose merge is mathematically guaranteed to converge: G-counters, PN-counters, OR-sets, LWW-registers). Two repair mechanisms keep replicas honest in the background: read repair (fix stale replicas when a read notices divergence) and anti-entropy (periodic Merkle-tree comparison between replicas).

Where caches live

The four cache patterns

Eviction policies

• LRU — evict least-recently-used. Good default; implemented as a hash map + doubly linked list (see L15 for full Java).
• LFU — evict least-frequently-used. Better when popularity is stable, but suffers from "cache pollution" by items that were hot long ago; real implementations use windowed/decayed counts.
• FIFO — simple, ignores access patterns, rarely right.
• TTL — not really eviction but the workhorse: bounded staleness with no invalidation logic at all. Always add jitter to TTLs so a million keys written together do not expire together.
• W-TinyLFU (Caffeine's default) — an admission filter using a frequency sketch in front of an LRU-ish window. Near-optimal hit rates; naming it is a strong signal.

The four cache failure modes you must be able to name

Redis, concretely

Redis is single-threaded for command execution (which is why every command is effectively atomic), in-memory, with optional persistence via RDB snapshots and/or an AOF append-only log. Its value is that it ships useful data structures, not just strings:

Why asynchrony is an architectural tool, not a detail

Putting a queue between a producer and a consumer buys four things: decoupling (they can be deployed and scaled independently), buffering (a traffic spike becomes a longer queue instead of an outage), retry (failed work stays in the queue), and fan-out (one event, many independent consumers). The cost is eventual consistency and a whole new class of bugs: duplicates, reordering, and poison messages.

Queue vs log — the distinction people get wrong

Kafka's mental model in five facts

1. A topic is split into partitions; each partition is an append-only, ordered log on disk.
2. The partition key decides ordering: all messages with the same key go to the same partition and are therefore strictly ordered relative to each other. Ordering is per-key, never global.
3. Parallelism is capped by partition count: within a consumer group, one partition is consumed by at most one consumer. 12 partitions → at most 12 useful consumers.
4. Each partition has a leader and followers (ISR = in-sync replicas). acks=all + min.insync.replicas=2 is the durable configuration.
5. Consumers store an offset. Committing it before processing gives at-most-once; committing after gives at-least-once. There is no free exactly-once.

Delivery semantics and the exactly-once myth

The transactional outbox — how to write to a DB and a queue atomically

You cannot commit a database transaction and publish to Kafka atomically; distributed transactions across them are unavailable in practice. If you write the DB then publish and crash in between, the event is lost. If you publish then write and the write fails, you have published a lie.

Operational realities to mention

• Dead-letter queue (DLQ) — after N failed attempts, move the message aside so one poison message does not block the partition, and alert on DLQ depth.
• Backpressure — if consumers cannot keep up, lag grows without bound. Monitor consumer lag as a first-class SLI; scale consumers up to the partition count, then add partitions.
• Ordering vs parallelism — these are in direct tension. If you need per-user ordering, partition by userId and accept that one slow user's messages block only that partition.
• Delayed / scheduled messages — SQS delay queues, RabbitMQ TTL+DLX, or a Redis ZSET keyed by execution time (see H16).

Block vs file vs object

How object storage achieves durability

Naive replication (3 copies) costs 3× storage. Erasure coding splits an object into k data fragments plus m parity fragments, spread across failure domains; any k of the k+m fragments reconstruct the object. A common (6,3) scheme survives 3 simultaneous failures at 1.5× storage instead of 4×. The trade-off: reconstruction on read is CPU-heavy and slower, so hot data often uses replication while cold data uses erasure coding. Storage classes (Standard → Infrequent Access → Glacier) formalise exactly this trade with lifecycle policies.

OLTP vs OLAP — and why you need both

The link between them is a pipeline: CDC or events from OLTP → Kafka → object storage (Parquet on a data lake) → warehouse. When an interviewer asks "how would the analytics team query this?", the answer is never "they'll query the production database."

Lambda vs Kappa architecture

Lambda runs a batch layer (accurate, slow, reprocesses everything) alongside a speed layer (approximate, real-time), and merges them at query time. Its flaw is maintaining the same logic twice. Kappa drops the batch layer: everything is a stream, and "reprocessing" means replaying the log from an earlier offset through a new version of the job. Kappa is simpler and possible because durable logs made replay cheap. Mention both in analytics designs (H15) and say why you'd pick Kappa.

Why LIKE '%query%' is not search

A leading wildcard cannot use a B-tree index, so it is a full table scan; it has no notion of relevance, no stemming, no typo tolerance, and no way to rank. Search needs a different index structure.

Ranking: TF-IDF and BM25

Term frequency — a term appearing often in a document suggests relevance. Inverse document frequency — a term appearing in every document (like "the") carries no information, so it is down-weighted. BM25 refines this with saturation (the 20th occurrence of a word adds much less than the 2nd) and length normalisation (a match in a short title beats one in a long body). You do not need the formula; you need to say why those two corrections exist. Modern systems then add a second stage: retrieve ~1000 candidates with BM25 or a vector index, then re-rank with a learned model using click-through, recency, and personalisation features.

Elasticsearch architecture, briefly

• An index is split into shards (each a self-contained Lucene index); each shard has replicas. Shard count is fixed at creation — a classic operational trap.
• A query scatters to all shards, each returns its local top-k, and the coordinator gathers and merges. Latency is bounded by the slowest shard.
• Lucene segments are immutable: writes go to a buffer, are flushed into new segments, and merged in the background. Deletes are tombstones. This means near-real-time, not real-time — the default refresh interval is 1 second.
• It is not a system of record. Keep the source of truth in your primary DB and stream changes into the index (via the outbox/CDC pattern from F12).

Availability arithmetic

Two facts that follow. Serial dependencies multiply: a request touching five services each at 99.9% has 99.5% availability — worse than any component. Redundancy adds nines: two independent components at 99% give 99.99% if failures are truly independent, which they usually are not (shared power, shared network, shared deploy, shared bug). Say that caveat out loud.

The patterns, in the order you should apply them

1. Timeouts on everything. A missing timeout is the single most common cause of cascading failure: threads pile up waiting on a dead dependency until the pool is exhausted and a healthy service goes down. Set the timeout from the p99 of the dependency, not from a round number.
2. Retries with exponential backoff and jitter — and only for idempotent, retryable errors (timeouts, 503, connection reset). Never retry a 400. Cap total attempts, and budget retries so a deep call chain does not multiply: 3 retries at each of 4 layers is 81 requests for one user action. Use a retry budget (e.g. retries may not exceed 10% of traffic).
3. Circuit breaker — after a failure threshold, stop calling the dependency entirely for a cooldown, fail fast, and periodically let one probe through (half-open). This converts a slow cascading failure into a fast, contained one.
4. Bulkhead — separate thread pools/connection pools per dependency so a slow one cannot consume all capacity. Named after ship compartments.
5. Load shedding — when overloaded, reject the cheapest-to-reject requests early (return 429/503 at the edge) rather than degrading everything. Prioritise: shed anonymous browsing before shedding checkout.
6. Graceful degradation — serve stale cache, hide the recommendations carousel, disable non-essential features. Decide the degradation ladder in advance and say what it is.
7. Hedged requests — for latency-sensitive reads, send a duplicate request to a second replica if the first has not answered by p95, and take whichever returns first. Cuts tail latency dramatically at a few percent extra load.

Why coordination is hard: the four impossibilities

• You cannot distinguish a slow node from a dead node. Every failure detector is a timeout, and every timeout is a guess. This is why fencing tokens exist.
• Clocks lie. NTP drift, leap seconds, and VM pauses mean wall-clock ordering across machines is unreliable. Use logical clocks (Lamport, vector clocks) for ordering; use wall clocks only for human-facing timestamps and TTLs.
• The FLP result — in a fully asynchronous system with even one faulty process, no deterministic algorithm guarantees consensus. Practical systems escape this with timeouts and randomisation.
• The two generals problem — no finite exchange of messages over a lossy channel gives both sides certainty. Hence: no true exactly-once delivery, only idempotency.

Consensus: Raft in one page

Distributed locks — and why they are a trap

Distributed transactions: 2PC vs Saga

The three pillars, and what each is for

• Metrics — cheap, aggregated numbers over time. Answer "is something wrong?" Use them for dashboards and alerts. Watch out for high-cardinality labels (never put userId in a Prometheus label — it will destroy the store).
• Logs — expensive, high-detail events. Answer "what exactly happened to this request?" Make them structured (JSON), sampled at high volume, and always carry a trace ID.
• Traces — the path of one request across services with per-span timing. Answer "which hop is slow?" This is the only tool that makes microservice latency debuggable.

The four golden signals

Latency (split successful vs failed — fast errors hide in an average), Traffic (requests/sec), Errors (rate and class), Saturation (how full is the most constrained resource: CPU, memory, connection pool, queue depth). If you can only have four dashboards, have these.

SLI / SLO / error budget

An SLI is a measurement ("proportion of requests served in under 300 ms"). An SLO is the target ("99.9% over 28 days"). The error budget is the remaining 0.1% — and its purpose is to make reliability a negotiation rather than an argument: budget left means ship features, budget exhausted means freeze and fix. Saying this framing back to an interviewer shows you understand why SLOs exist organisationally, not just technically.

Deployment strategies

Multi-region

Active-active forces a choice on write conflicts: partition users by home region so a given record is only written in one place (best), use CRDTs for genuinely concurrent data, or accept last-write-wins and its data loss. Also state the two acronyms explicitly — RTO is how long recovery takes; RPO is how much data you can afford to lose.

Sessions vs tokens

The production compromise: a short-lived access token (5–15 min, stateless, fast) plus a long-lived refresh token (stored server-side, revocable, rotated on each use with reuse detection). Say that pairing and the reasoning — you get stateless verification on the hot path and real revocation on the cold path.

OAuth 2.0 / OIDC in one paragraph

OAuth 2.0 is an authorisation delegation protocol: it lets an app act on a user's behalf at another service without the user handing over a password. OIDC layers authentication on top by adding an ID token. The flow you should name is authorisation code with PKCE: the client redirects to the identity provider, the user consents, the provider returns a one-time code to a registered redirect URI, and the client exchanges that code (plus a proof key it generated) for tokens. Note the common confusion in interviews: OAuth is not authentication — "log in with Google" is OIDC.

Abuse and rate limiting

Rate limiting protects capacity, cost, and fairness. The full design is case study H2; here are the algorithms in one table.

The rest of the security checklist

• Encryption — TLS 1.3 in transit; AES-256 at rest with keys in a KMS/HSM, rotated. Field-level encryption for the most sensitive columns.
• Passwords — bcrypt, scrypt, or Argon2id with a per-user salt. Never SHA-256, never MD5, never unsalted. Argon2id is the current recommendation.
• Authorisation — RBAC for coarse roles, ABAC for context-dependent rules. Check permissions at the service, never only in the UI. IDOR (changing /orders/123 to /orders/124) is the most common real-world API vulnerability.
• Input — parameterised queries (SQL injection), output encoding + CSP (XSS), size limits and content-type validation on uploads.
• Secrets — a secrets manager, never environment variables committed to a repo; short-lived credentials via workload identity where possible.
• PII — data minimisation, retention limits, deletion pipelines that reach backups and derived stores. If you design for a global product, mention GDPR's right to erasure and how your event log complicates it (crypto-shredding: delete the per-user key so the ciphertext becomes unreadable — an elegant answer worth knowing).

The honest comparison

API gateway — what belongs in it

Cross-cutting concerns that should not be reimplemented in every service: TLS termination, authentication and token validation, rate limiting, request routing and versioning, request/response transformation, caching of idempotent GETs, and observability injection (trace IDs). What does not belong: business logic. A gateway that knows about orders is a distributed monolith with extra latency.

A BFF (Backend for Frontend) is a per-client-type gateway — one for mobile, one for web — that aggregates and reshapes responses for that client's needs. It exists because a mobile client on a slow network wants one 8 KB call, not six 2 KB calls. Service mesh (Envoy sidecars, Istio/Linkerd) moves retries, mTLS, circuit breaking, and traffic-splitting out of application code and into the infrastructure layer — a legitimate answer when asked "how do you enforce retry policy consistently across 40 services?"

API design details interviewers probe

• Versioning — URI (/v1/) is the pragmatic default; header-based is purer but harder to debug. Better still: never break — add fields, never remove or repurpose them, and treat unknown fields as ignorable.
• Pagination — cursor over offset (F1). Return an opaque nextCursor so you can change the underlying strategy later.
• Idempotency — an Idempotency-Key header on all unsafe operations, with the result stored for 24 hours.
• Errors — a consistent envelope with a machine-readable code, a human message, and a request ID the user can quote to support. Use the right status: 400 malformed, 401 unauthenticated, 403 unauthorised, 404 missing, 409 conflict, 422 semantically invalid, 429 rate-limited, 503 overloaded.
• Bulk endpoints — one call that accepts 100 IDs is worth more than any latency micro-optimisation on a chatty client.
• Long-running work — return 202 Accepted with a status URL rather than holding the connection.

Each case study follows the same skeleton, which is also the skeleton you should follow in the room: requirements → numbers → API and data model → simple design → the one hard problem → failure modes → follow-ups. The "one hard problem" line is the important one — every classic question has a single central difficulty, and interviewers are waiting to see whether you find it.

Requirements

• Functional: shorten a long URL; redirect a short URL to the original; optional custom alias; optional expiry; basic click analytics.
• Non-functional: redirect latency < 100 ms at p99 (it sits in front of a page load); very high availability (a dead shortener breaks every link ever shared); read-heavy 10:1 or more; short links must be non-guessable enough to not enumerate a competitor's links.
• Scale: 100M new URLs/day, 1B redirects/day → ~1,000 writes/s and ~12,000 reads/s average, ~35,000 reads/s peak.

How short is short?

Key generation — the actual interview question

Data model and API

Architecture

301 or 302? A 301 (permanent) lets the browser and intermediaries cache the redirect forever — which is great for latency and load, and terrible for analytics, because subsequent clicks never reach you. A 302 (temporary) guarantees every click hits your server. Answer: 302 if analytics matter, 301 with a short Cache-Control max-age if load matters. Being asked this and knowing the analytics implication is the entire point of the question.

Bottlenecks and follow-ups

• Hot links — one viral link can be 10% of all traffic. It will be cached, so this is mostly fine; add an in-process LRU on each app node for the top few thousand keys to avoid even the Redis hop.
• Analytics — never write to a database on the redirect path. Emit to Kafka, aggregate in a stream processor, store in a columnar store. Redirect latency must not depend on analytics availability.
• Expiry — a TTL on the KV store handles it for free; otherwise a batch cleanup job. Say that TTL cuts your 73 TB estimate dramatically.
• Abuse — shorteners are used to hide phishing. Check submissions against a safe-browsing API asynchronously and disable links on a hit; rate-limit creation per account and IP.
• Custom aliases — same table, but writes must go through a uniqueness check, and you should reserve a blocklist (profanity, admin, login).

Requirements

• Functional: limit requests per identity (user, API key, IP) per rule; return 429 with Retry-After and X-RateLimit-* headers; support multiple tiers (free/paid) and multiple granularities (per-second and per-day simultaneously).
• Non-functional: adds < 5 ms to a request; must not become a single point of failure; must work across hundreds of API server nodes; approximate is acceptable at the edges.

Where does it live?

Three options: client-side (unreliable — a client can simply not implement it), in the API gateway / middleware (the usual answer — centralised, protects everything behind it), or as a separate service (flexible, but adds a network hop to every request). Choose the gateway, and say why: it is the first place that can reject a request before it consumes any downstream capacity.

Algorithm choice

See the table in F18 for all five. In a design round, pick token bucket for public APIs (bursts are user-friendly and it is trivially explained) or sliding window counter when smoothness matters more than burst tolerance. Then show the implementation.

Making it distributed

The naive approach — each node keeps its own counter — means N nodes allow N× the limit. Three fixes:

1. Central store (Redis). All nodes read/modify/write the same key. Correct, but the read-modify-write must be atomic or concurrent requests will over-admit. Use a Lua script (single round trip, atomic on Redis's single-threaded executor). This is the standard answer.
2. Sharded limits. Give each of N nodes limit/N and route each identity consistently to one node (consistent hashing). No shared state and no network hop, but uneven traffic wastes budget.
3. Local + async sync. Each node enforces locally and gossips counts every few hundred ms. Fast and highly available, over-admits slightly during the sync interval. Used by systems that need microsecond decisions.

Response contract

Requirements

Globally unique; 64-bit (fits a BIGINT and a Java long); roughly time-sortable (so that a primary-key index has good insert locality and "newest first" needs no extra index); at least 10,000 IDs/sec per node; no central coordinator on the hot path.

This is really an oral exam on F8, F9, and F10 combined. The expected answer is a Dynamo-style design; walk through it as a set of decisions.

Requirements

get(key) and put(key, value) with values up to ~10 KB; scale to petabytes; configurable consistency; high availability during node and network failures; automatic scaling and rebalancing.

The seven decisions

Requirements

• Functional: given seed URLs, download pages, extract links, repeat; store page content for downstream indexing; re-crawl pages based on how often they change.
• Non-functional: politeness (never overwhelm a host, obey robots.txt), scale to a billion pages/month, extensible to new content types, robust against traps.
• Scale: 1B pages/month ≈ 400 pages/s average, ~1,200/s peak; 500 KB average page → 500 TB/month of raw content.

The URL frontier is the whole problem

Deduplication at scale

• URL seen? — you cannot keep 100 billion URLs in a hash set. Use a Bloom filter (probabilistic, no false negatives, ~1% false positive means you occasionally skip a page — acceptable) backed by a sharded key-value store for exactness where it matters. Normalise URLs first: lowercase host, strip fragments, sort query parameters, drop tracking parameters.
• Content seen? — exact duplicates via a hash of the body. Near-duplicates (same article on 50 mirrors) via SimHash: documents within a small Hamming distance are treated as duplicates. Mentioning SimHash or MinHash specifically is the depth signal here.

Traps and hazards to volunteer

• Spider traps — infinitely deep calendar URLs, session-ID query parameters generating unbounded URLs. Defences: max depth, max URLs per domain, URL pattern blocklists, and manual review of the top-N domains by URL count.
• Robots.txt — fetch and cache per host with a TTL; respect Crawl-delay and Disallow. Ignoring it gets you IP-banned and is a legal risk — say this.
• JavaScript-rendered pages — a plain HTTP fetch gets an empty shell. A headless-browser rendering tier is 10–100× more expensive per page, so run it selectively based on whether the static HTML looked empty.
• Re-crawl policy — do not crawl everything at the same frequency. Estimate a per-page change rate from history and schedule accordingly; a news homepage may be hourly, a 2011 forum thread yearly.
• Coordination — shard the frontier by hash(host) so politeness state for a host lives on exactly one node, which turns a distributed-locking problem into a partitioning decision.

Requirements

• Functional: send push (iOS/Android), SMS, email, and in-app notifications; triggered by services or by scheduled campaigns; users can opt out per channel and per category; templates with variables; retries.
• Non-functional: 10M notifications/day with bursts of 100k/s during campaigns; at-least-once delivery with deduplication; a third-party outage must not lose messages; soft real-time (seconds) for transactional, best-effort for marketing.

The five hard parts

1. Device token management. A user has many devices; tokens expire, get revoked, or transfer to another user when a phone is resold. Store (userId, deviceToken, platform, appVersion, lastSeen), and process the provider's feedback — APNs/FCM tell you when a token is invalid, and continuing to send to dead tokens gets your sender reputation throttled.
2. Deduplication. At-least-once queues mean a worker crash after sending but before acking causes a duplicate push, which users experience as spam. Fix with an idempotency key (userId, notificationId, channel) written to a store with a TTL, checked before send (F12).
3. Third-party unreliability. Providers rate-limit you, go down, and return ambiguous errors. Each worker needs a circuit breaker, a token-bucket limiter matched to the provider's quota, exponential backoff, and a DLQ. For critical channels, keep a secondary provider and fail over — then be explicit that failover risks duplicates, so idempotency must be provider-independent.
4. Priority and throttling. A marketing blast of 5M messages must never delay a password-reset email. Separate priority lanes (or separate topics) with dedicated worker pools, plus a per-user frequency cap ("no more than 3 marketing pushes per day") enforced centrally rather than by each producing service.
5. Fan-out. "Notify all followers of X" can be one request producing 10M messages. Do not expand it in the API handler. Write a single campaign record, then have a fan-out job stream the recipient list in pages and emit per-recipient messages, with checkpointing so a crash resumes rather than restarts.

Requirements

• Functional: post; follow/unfollow; view a home timeline of posts from people you follow, newest first (or ranked); view a user's own profile timeline.
• Non-functional: home timeline loads in < 200 ms at p99; extremely read-heavy (~1000:1); a few seconds of staleness is acceptable; high availability.
• Scale: 300M DAU, 300M posts/day (~3,500/s), ~300k timeline reads/s peak, average 200 followers with a long tail up to 100M+.

The core decision: fan-out on write vs fan-out on read

Data model

Follow-ups you should pre-empt

• Ranking instead of chronological — the feed becomes: candidate generation (the merged set above, plus recommendations) → feature extraction → an ML ranker → business rules (diversity, ads, freshness). Say that ranking sits after candidate generation, so the storage design does not change.
• Unfollow / delete — do not attempt to remove the post from millions of materialised timelines. Filter at read time against a small "deleted posts" bloom filter or check on hydration, and let the entry age out of the capped list.
• New follow — backfill that user's recent posts into your timeline asynchronously, or simply let them appear from the next post onwards. Say which and why.
• Media — post rows carry only media IDs; the bytes are in object storage behind a CDN (F13).

Requirements

• Functional: 1:1 and group chat (up to 500 members); message delivery with sent/delivered/read receipts; online presence; offline message delivery; media attachments; message history.
• Non-functional: end-to-end latency < 200 ms for online users; no message loss; correct ordering within a conversation; 50M DAU with ~10M concurrent connections.

Message flow, step by step

1. A sends over its WebSocket with a client-generated clientMessageId (UUID). This is the idempotency key that makes retries safe when A's network flaps.
2. The gateway hands it to the message service, which assigns a server-side ID and, critically, a per-conversation sequence number.
3. Persist before acknowledging. The ack to A means "durably stored", which is what a single tick means in the UI.
4. Look up B in the session store. If online, publish to B's gateway node (via Redis pub/sub or Kafka keyed by nodeId) which writes it to B's socket → two ticks. If offline, the message simply stays in the store, and a push notification is sent.
5. When B connects, it sends its last-seen sequence number per conversation and the server streams everything after it — a pull-based sync that is far more robust than trying to queue per-recipient.

The four hard parts

Requirements

• Functional: given a prefix, return the top 5–10 most popular completions; support new/trending queries; ignore inappropriate terms.
• Non-functional: < 100 ms end-to-end — it must feel instantaneous while typing; extremely read-heavy; results may be minutes stale.
• Scale: 10M searches/day; every keystroke is a potential request, so ~20 requests per search → a 20× amplification over search traffic itself.

The data structure: trie with precomputed top-k

Architecture: separate the read path from the build path

Scaling the trie

A full trie over hundreds of millions of terms will not fit in one process. Shard by prefix — but not naively by first letter, because 's' has vastly more terms than 'z'. Use a learned prefix split: measure the distribution and assign ranges so each shard carries similar load (e.g. shard 1 = 'a'–'ac', shard 2 = 'ad'–'am'…), with a small routing map cached on the client-facing tier. Since the trie is rebuilt offline anyway, recomputing the split each build is free.

Requirements

• Functional: upload video; watch video with adaptive quality; view counts; basic search and recommendations (park these).
• Non-functional: playback starts in < 1 s; no buffering on variable networks; upload of a 10 GB file must survive a dropped connection; global audience.
• Scale: 500 hours uploaded per minute; 5M concurrent viewers; average watch bitrate 2 Mbps → 10 Tbps of egress. That number, not storage, is the design driver — and cost is a legitimate first-class concern here.

Upload path

Transcoding: a DAG, not a script

Playback: adaptive bitrate streaming

The video is stored as many independent segments per quality level, described by a manifest (HLS .m3u8 or DASH .mpd). The player — not the server — decides which quality to request for the next segment based on measured throughput and buffer level. That is why streaming scales: the server just serves static files, and all the adaptation logic is on the client. Start with a low-bitrate segment so playback begins fast, then ramp up.

Delivery and cost

• CDN is mandatory, and the cache hit ratio is the whole economic story. Popularity is extremely skewed — a small fraction of videos gets most views — so a modest edge cache serves the vast majority of traffic. Long-tail videos are served from a regional origin.
• Tiered storage — hot videos on fast storage with all renditions; cold videos moved to cheap storage, and rarely-watched renditions deleted and regenerated on demand. Naming this trade (storage cost vs re-transcode cost) is a strong signal.
• Pre-positioning — for a scheduled premiere or a major sports event, push content to edge caches before the event rather than letting 5M simultaneous first-viewers all miss.
• Signed URLs with short expiry for access control, so the CDN can serve private content without calling your auth service per segment.
• View counts are not a database UPDATE — they are events into a stream aggregator (H15), with dedupe rules (a "view" is typically 30 s of playback, once per user per window, to resist inflation).

Requirements

• Functional: upload/download files; sync across devices automatically; share with other users; version history; work offline and reconcile on reconnect.
• Non-functional: sync must be bandwidth-efficient (do not re-upload a 2 GB file because one byte changed); strong durability; conflicts must never silently lose data.

The central idea: chunking + content-addressed storage

Sync protocol

1. Client watches the local folder and computes chunk hashes for changed files.
2. It asks the server which of those chunk hashes are already known (POST /chunks/check) — a cheap way to skip uploading anything the system already has.
3. It uploads the missing chunks directly to object storage, then commits a new file version to the metadata service with the previous version ID (an optimistic concurrency check).
4. Other devices are told "namespace changed since cursor X"; they pull the metadata delta and download only the chunks they lack. A cursor-based delta, not a full listing — this is what keeps sync O(changes) instead of O(files).

Conflicts

Two devices edit offline and both commit against version 7. The second commit fails its optimistic check. Do not merge binary files and do not overwrite. The correct product behaviour is to keep both: create report (Alice's conflicted copy).pdf and surface it. For text-like formats, an operational-transform or CRDT layer can merge (see H19), but for general files, preserving both and telling the user is the honest answer — and saying "silently losing a user's work is the one unacceptable outcome" frames it correctly.

Requirements

• Functional: drivers broadcast location; riders request a ride; the system matches a nearby driver; both track each other live; trip lifecycle and pricing.
• Non-functional: matching in < 5 s; location updates every 4 s from every active driver; a rider must never be matched to two drivers, nor a driver to two riders.
• Scale: 1M active drivers → 250k location writes/s. That write rate is the first thing to notice, and it rules out a normal relational table with a spatial index.

Geospatial indexing — the actual question

This is the counterpoint to the feed questions: here eventual consistency is wrong. Double-selling one seat is a business failure, so the design must be consistent where it counts and only optimistic elsewhere.

Requirements

• Functional: browse events; see a seat map; hold seats while paying; complete purchase; release abandoned holds.
• Non-functional: no double-booking, ever; survive a burst of 100k users at an on-sale moment for 20k seats; the browse path should stay available even under that burst.

Design

Handling the on-sale burst

• Virtual waiting room. Admit users into the purchase flow at a controlled rate (a token/queue system at the edge). This converts an unbounded burst into a steady stream the transactional core can absorb, and gives users an honest position indicator instead of an error page.
• Bot defence. The real burst is scalpers, not fans: CAPTCHA, device fingerprinting, per-account and per-payment-instrument limits, and account-age requirements. Say it, because it is the actual production problem.
• Hold TTL tuning. Too short and users on slow connections lose seats mid-payment; too long and inventory is locked by abandoned carts. 10 minutes with a visible countdown is the norm.
• Fairness. Randomised admission from the waiting room is fairer than strict FIFO (which rewards whoever had the fastest connection at the exact millisecond) — and less exploitable.

Requirements

• Functional: accept a payment for an order; support cards via a PSP (Stripe/Adyen); handle refunds; produce an auditable record of every money movement; reconcile with the provider daily.
• Non-functional: never double-charge; never lose a payment record; every state change auditable and immutable; correctness beats latency and beats availability.

Three non-negotiable design elements

Requirements

• Functional: ingest click events; return click counts per ad per minute; support "top N ads in the last M minutes"; support filtering by dimensions (country, device).
• Non-functional: 1M events/s; dashboard freshness within ~1 minute; accuracy matters — advertisers are billed from these numbers, so duplicates and losses are financial errors; must tolerate late-arriving events.

The four hard parts

1. Exactly-once counting. At-least-once delivery plus naive counting means over-billing. Solutions: assign each click a unique clickId at the edge and deduplicate within the window (a Bloom filter or a per-window key set); use Flink's checkpointed state with two-phase-commit sinks; or make the sink idempotent by writing (adId, minute) → count as an overwrite of a recomputed window value rather than an increment. The overwrite trick is the simplest to explain and defend.
2. Event time vs processing time. A click at 12:00:59 may arrive at 12:01:30 because of a mobile network delay. Aggregating by arrival time puts it in the wrong minute. Use event time with a watermark — "I will wait up to 2 minutes for stragglers, then close the window" — and route anything later than that to a late-data path that issues a correction. Being able to explain watermarks concretely is the depth signal in this question.
3. Hot keys. A viral ad concentrates on one Kafka partition. Fix with two-stage aggregation: pre-aggregate locally per task with a salted key (adId#0..9), then combine — the same counter-sharding idea from F10.
4. Fraud. Click fraud is the real product problem: dedupe by (userId, adId, minute), filter known bot signatures, cap per-IP rates, and keep a separate "billable" pipeline whose output is what advertisers are charged, downstream of fraud filtering, so the raw and billable numbers can differ and be reconciled.

Requirements

Schedule one-off and recurring jobs; execute at (or shortly after) the requested time; at-least-once execution with idempotent handlers; retries with backoff; visibility into job state; millions of scheduled jobs, thousands executing per second.

Requirements

Collect metrics from 100k hosts; store at 10-second resolution; query arbitrary time ranges with aggregation; alert on thresholds; retain 13 months. That is ~10M data points/second at peak — the write path is the design.

Shorter treatments. For each, the requirement that matters, the central insight, and the trap.

Design S3 / an object store

Central insight: separate the metadata plane (bucket → object key → chunk locations, a sharded KV store) from the data plane (immutable chunks on dumb storage nodes). Objects are immutable — an "update" writes a new version and repoints metadata, which makes replication and caching trivial. Durability comes from erasure coding across failure domains (F13); a background scrubber continuously reads and re-verifies checksums to catch bit rot before it compounds. Trap: proposing a POSIX filesystem. Object stores are flat namespaces precisely because directory trees require expensive hierarchical locking and rename semantics.

Design a leaderboard

Central insight: Redis sorted sets. ZADD leaderboard score userId, ZREVRANGE 0 9 for the top 10, ZREVRANK for a player's own rank — all O(log n). Scale problem: 50M players in one ZSET is memory-heavy and every write touches one key. Fix by sharding into buckets by score range and maintaining a small top-N set separately; approximate ranks for players outside the top few thousand ("top 12%") since nobody in rank 4,000,000 needs an exact number. Trap: computing rank with SELECT COUNT(*) WHERE score > x in a relational DB — correct and completely unscalable.

Design a digital wallet

Central insight: it is H14's ledger with a stricter constraint — balances cannot go negative, and transfers are between two internal accounts. Model every transfer as a double-entry pair inside a single transaction if both accounts are in one shard; if they are on different shards, use a saga with a reserved/pending state (F16). Trap: using a mutable balance column. Use the ledger plus periodic snapshots, and enforce the non-negative constraint at the database level (CHECK or a conditional update), never only in application code.

Design Google Docs (collaborative editing)

Central insight: concurrent edits to shared text need either OT (operational transformation — transform incoming operations against concurrent ones so all clients converge; what Google Docs uses, requires a central server to order operations) or CRDTs (data types whose merge is commutative and associative by construction, so no central authority is needed; used by Figma, Yjs, Automerge). Both converge; OT is more bandwidth-efficient but harder to get right, CRDTs are simpler to reason about but carry metadata overhead per character. Trap: proposing last-write-wins on the whole document — it silently discards a collaborator's paragraph.

Design a proximity service (Yelp "restaurants near me")

Central insight: unlike Uber (H12), the businesses barely move — so this is a read-heavy, write-rare geospatial problem, which means you can precompute aggressively. Store a geohash or S2 cell ID as an indexed column in a normal database, query the user's cell plus neighbours, then filter by exact distance and rank by rating/relevance. Cache per-cell result sets, since thousands of users in the same cell get the same candidate list. Trap: reaching for the Uber design. Recognising that a different write pattern permits a much simpler answer is the skill being tested.

Design a stock exchange / order matching engine

Central insight: the matching engine is deliberately single-threaded and in-memory — a limit order book as two priority queues (bids descending, asks ascending) with price-time priority. Determinism and microsecond latency matter more than horizontal scale, and one core can match millions of orders per second. Durability comes from an append-only input log replicated to hot standbys that replay the same deterministic sequence (event sourcing), not from a database write per trade. Shard by symbol, since orders for different symbols never interact. Trap: distributing the matching engine itself — that destroys the deterministic ordering that fairness and auditability depend on. This is the clearest example in the whole manual of a case where not distributing is the senior answer.

A machine-coding round gives you 60–120 minutes and a prompt like "design a parking lot" or "build Splitwise." You produce working, compiling Java plus a class design you can defend. It is graded far more on structure than on features.

What is actually scored

The 90-minute plan

1. 0–8 min — clarify and freeze scope. Write the requirements as a comment block at the top of the file. Explicitly list what is out of scope. This is your contract, and it protects you when time runs short.
2. 8–20 min — identify entities and relationships. Nouns become classes, verbs become methods. Sketch the class diagram (on paper or as comments) and say which patterns you will use and why.
3. 20–70 min — code, bottom-up. Enums and value objects → entities → repositories (in-memory) → services → strategies → the demo. Compile every 10 minutes.
4. 70–85 min — the demo. A main covering the happy path and one edge case.
5. 85–90 min — narrate extensions. "To add a bike-only floor, I'd add one enum value and one strategy implementation; no existing class changes."

The four pillars, stated usefully

• Encapsulation — hide state behind behaviour. The test: can an external caller put the object into an invalid state? If a BankAccount exposes setBalance(), it can. Expose deposit() and withdraw() instead, and validate inside.
• Abstraction — expose what, hide how. A PaymentGateway interface with charge(amount) lets you swap Stripe for Razorpay without a caller noticing.
• Inheritance — an "is-a" relationship for sharing behaviour. Powerful and over-used; see composition below.
• Polymorphism — one interface, many implementations, resolved at runtime. This is what lets you delete if (type == CAR) ... else if (type == BIKE).

Composition over inheritance — the single most useful principle in LLD

Interface vs abstract class

Modern Java tip worth mentioning: sealed interfaces plus records give you a closed set of implementations the compiler can exhaustively check in a switch — very useful for modelling a fixed set of events, commands, or states.

Equals / hashCode — the detail that gets noticed

S — Single Responsibility

A class should have one reason to change. The practical test: can you describe what it does without saying "and"?

O — Open/Closed

Open for extension, closed for modification. In practice: a growing if/else or switch on a type is the smell, and polymorphism is the cure.

L — Liskov Substitution

A subtype must be usable anywhere its supertype is, without the caller knowing. Violations look like: throwing UnsupportedOperationException in an override, strengthening preconditions, or weakening postconditions.

I — Interface Segregation

No client should be forced to depend on methods it does not use. Many small role interfaces beat one fat one.

D — Dependency Inversion

High-level modules should depend on abstractions, not on concrete low-level classes. This is what makes code testable.

For a 90-minute round you do not need a UML tool. A boxes-and-lines sketch with multiplicities, or even a comment block listing classes with their fields and relationships, is enough — what matters is that you can explain the relationships and defend the ownership choices.

These control how objects come into existence, so that callers do not depend on concrete classes or on complex construction logic.

Singleton — exactly one instance

Factory Method and Abstract Factory

Builder — the one you will actually use

Prototype completes the family: when constructing an object is expensive (a heavy parsed config, a pre-populated game board), clone() an existing instance instead. In Java, prefer a copy constructor or a toBuilder() method over Cloneable, which has a famously broken contract — and say so if asked.

These compose objects into larger structures without making the composition rigid.

Why this beats a switch: every state class holds all the behaviour for that state, including which actions are illegal, so adding a MaintenanceState cannot break the others. And the return type makes transitions explicit — you can read the machine's graph by scanning the return statements.

Almost every machine-coding prompt has a hidden concurrency requirement — two cars arriving at the same spot, two users booking the same seat, two threads incrementing the same counter. You are not expected to build a thread pool from scratch; you are expected to pick the right primitive and justify it.

The primitives, ranked by how often you should reach for them

Requirements (freeze these in the first five minutes)

• Multi-floor lot; spot types for motorcycle, car, and truck; a vehicle may occupy a compatible spot.
• Park a vehicle → issue a ticket. Unpark → compute a fee and free the spot.
• Pluggable spot-allocation policy and pluggable pricing.
• Thread-safe: many entry gates operate concurrently.
• Out of scope: persistence, reservations, valet, number-plate recognition, real payment gateways.

Requirements

• N elevators serving F floors. Two request sources: an external hall call (floor + up/down) and an internal car call (destination floor from inside).
• A controller assigns hall calls to the best car; each car serves its own stop list efficiently (do not reverse direction unnecessarily).
• Pluggable dispatch policy; doors open/close; capacity limits; a maintenance mode.
• Out of scope: physics, real motors, emergency systems.

The LLD counterpart to H13. Everything here hinges on one question: can two users book the same seat? Design so the answer is structurally no.

Requirements

• Cities → theatres → screens → shows (a movie on a screen at a time). Seats per screen with types and prices.
• Search shows; view seat availability; hold selected seats for 10 minutes; confirm after payment; auto-release expired holds.
• Thread-safe under concurrent booking. Out of scope: real payments, persistence, recommendations.

Requirements

• Users and groups. Add an expense paid by one or more users, split among participants.
• Split types: EQUAL, EXACT amounts, PERCENT. Extensible to more.
• Show per-user balances ("you owe Rohit ₹450"). Simplify debts within a group.
• Out of scope: multi-currency conversion, settlements via real payment rails, persistence.

The requirement is O(1) get and put. That constraint alone dictates the design: a hash map for lookup, plus a doubly linked list for recency ordering, with the map storing node references so any node can be unlinked in constant time.

Thread-safe token bucket

Two points to narrate: refill is computed from elapsed time rather than run by a background thread (one timer thread for a million keys would not scale), and the lock is per bucket so unrelated users never block each other. Then connect to the HLD version: "across many servers I'd move this state into Redis with the Lua script from H2, because otherwise N nodes each allow the full limit."

A logging framework (Chain of Responsibility + Strategy)

For each: the entities, the pattern that carries the design, and the trap.

Tic-tac-toe / Connect Four

Entities: Board, Cell, Player, Move, Game, WinningStrategy. Pattern: Strategy for win-detection so a 3×3, an N×N, and Connect Four share one Game. Trap: checking all rows, columns, and diagonals after every move — O(N²). Keep running counts per row, column, and the two diagonals and check only the four affected by the last move: O(1). Interviewers ask for exactly this optimisation.

Snake and Ladder

Entities: Board (a map of jump start → end), Dice, Player, Game with a turn queue. Pattern: Strategy for dice (a real die vs a loaded die for testing — this makes the game deterministically testable, which is the point). Trap: modelling snakes and ladders as two separate classes; they are the same thing — a jump — differing only in direction.

Chess

Entities: Board, Cell, abstract Piece with subclasses, Move, Game, Player. Pattern: polymorphic canMove(board, from, to) per piece — the textbook use of inheritance. Trap: forgetting the moves that break the "piece decides" model: castling, en passant, and promotion involve two pieces or a state change, so they belong on Game/MoveValidator, not on Piece. Naming that boundary problem is what separates a good answer here.

In-memory file system

Entities: FileSystemNode with FileNode and DirectoryNode. Pattern: Composite (L6) — size(), delete(), and search() recurse uniformly. Trap: path resolution. Write a single resolve(String path) that splits on / and walks the tree, and reuse it everywhere; candidates who re-parse paths inside every method produce a mess.

Key-value store with TTL

Entities: Store wrapping a ConcurrentHashMap<String, Entry> where Entry holds value + expiresAtNanos. Design point: combine lazy expiry (check on read and treat expired as absent) with active expiry (a background sweeper sampling random keys, exactly like Redis). Lazy alone leaks memory for keys never read again; active alone is too expensive to be exhaustive. Trap: using a Timer per key — a million keys means a million timers.

Notification service

Entities: Notification, Channel, UserPreferences, NotificationService. Patterns: Observer (subscribers react to events) + Strategy (one sender per channel) + Factory (pick the sender). Trap: synchronous sending inside the business transaction — if the email server hangs, the order hangs. Queue it, as in H6.

Uber cab matching (LLD scope)

Entities: Rider, Driver, Trip, Location, TripState, MatchingStrategy. Patterns: State for the trip lifecycle (REQUESTED → ASSIGNED → STARTED → COMPLETED, with only legal transitions), Strategy for matching (nearest, highest-rated, surge-aware), Observer for trip-status updates to both parties. Trap: the double-assignment race — use an atomic compare-and-set on the driver's state exactly as in the parking lot (L9), not a mutable boolean.

Five-minute pre-submit checklist

• It compiles, and main runs a happy path plus one failure path.
• Requirements and out-of-scope items are written at the top as comments.
• Every interface has at least two conceivable implementations (otherwise inline it).
• No business logic in entity setters; no System.out.println inside services.
• Shared mutable state is either confined, atomic, or guarded — and I can say which.
• Money is integer minor units; times are Instant, injected rather than Instant.now() deep inside logic.
• Exceptions are specific (SeatsUnavailableException), not bare RuntimeException.
• Collections returned from getters are copies or immutable views.
• I can name the two extensions I would make next and which class each touches.

What follows is a compressed 45-minute round. The annotations in the margin notes are what the interviewer is thinking.

Four weeks (interview is close)

Eight weeks (building real depth)

Same as above at half pace, plus: implement one thing per week for real — a consistent hash ring with a rebalancing test, a token-bucket limiter backed by Redis, an LRU cache benchmarked against LinkedHashMap, a small Kafka consumer that is genuinely idempotent. Building beats reading by a wide margin, because the details you get wrong are exactly the details interviewers probe.

Cover the answer, say yours out loud, then check. Aim for two sentences each.