Recurring deep-dive patterns

Case studies feel different until you strip away the domain nouns. A news feed, a ticket sale and a chat app recombine the same few patterns. This page is the map: problem class, default tools, and where to practice them. Use it to prepare for interviews, and to recognize familiar shapes in design docs.

If you need a 45-minute structure for applying these, see the interview framework.

Concepts in this section

Read the pages in this order. The first one is a basic prerequisite for the rest.

Step	Concept	What it answers
1	Scaling reads and writes	Which tools spread read load, and which spread writes?
2	Hot keys and celebrities	What do you do when one key gets most of the traffic?
3	Contention and holds	How do many clients claim one scarce unit safely?
4	Multi-step consistency	How do two systems stay in agreement?
5	Realtime and long-running work	How do you push live updates and finish slow jobs?

The pattern map

Each class has default tools. Reads use replicas, caches and CDNs. Writes use sharding, queues and suitable stores. Hot keys use splitting, local caches and hybrid fan-out. Contention uses conditional updates, holds and waiting rooms. Large media uses presigned uploads and a CDN. Realtime uses SSE, WebSockets and pub/sub. Long work uses jobs and webhooks. Multi-step consistency uses sagas, outboxes and idempotency.

How to use this in an interview

Clarify the requirements until you know which problem class dominates.
Name the pattern out loud, such as "this is a hold with a time-to-live plus a waiting room".
Go deep on one or two patterns, with numbers. Name the rest as boxes with one line each.
Name the failure modes, such as a stampede, a double charge, or an origin overload.

Trade-off

In a 45-minute interview, you cannot deep-dive every pattern. Pick the hardest constraint, usually contention, money or fan-out, and spend 15 to 20 minutes there.

Anti-patterns

Smell	Prefer instead
`SELECT FOR UPDATE` on every seat in a flash sale	Conditional update and a waiting room
Float column for currency	Integer minor units and a ledger
Uploads proxied through app servers	Presigned multipart upload to object storage
Polling every 500 ms from millions of clients	SSE or WebSockets with pub/sub
Video encoding inside the upload request	Queue and workers
Fan-out on write to 50 million followers	Hybrid fan-out for celebrities

Estimating the dominant pattern

Quick filters from the requirements:

Reads far outnumber writes          -> scale reads first
Unique inventory plus a spike       -> contention first
Payloads above a few MB             -> media upload path first
Live typing or tokens               -> realtime delivery first
Money or stock across services      -> multi-step consistency first
One key gets 10% of the traffic     -> hot keys first

Run a quick estimate to confirm the pick. A wrong guess wastes the interview on caching when the real problem is double booking.

Common mistakes

Naming a pattern without tools. Attach defaults to each pattern, such as "TTL hold, conditional update, waiting room".
Ignoring the glue patterns. Idempotency and admission control keep the main pattern correct under failure.

Key takeaways

Domains change, but problem classes recur. Learn the class, not the company.
Reads use replicas, caches and CDNs. Writes use sharding, queues and suitable stores.
Unique inventory needs holds and conditional updates. Money needs idempotency, a ledger and reconciliation.
Multi-step flows use sagas, outboxes and idempotency, not two-phase commit by default.