Label the pattern before drawing boxes
Spend the first thirty seconds of a system design question naming which of ten known patterns it is. The building blocks and trade-offs follow from the label.
Original The Only System Design Cheatsheet by Puneet Patwari
The idea
Most system design questions are one of a small set of recurring shapes. If you name the shape out loud before you sketch anything, the architecture gets simpler, the trade-offs you raise are the right ones, and the answer stops sounding like a list of buzzwords.
Four quick questions do the classifying: are reads or writes dominant, do users need updates now or is near real time fine, is the value in serving live traffic or crunching data later, and is it one user at a time or fanout to millions.
Most real systems combine two or three patterns. Saying which one is primary and which are secondary is itself a strong signal.
The ten patterns
| Pattern | Tell-tale signal | Trade-off to raise |
|---|---|---|
| Read heavy | Read:write ratio is huge; latency matters more than freshness | What to cache at which layer, invalidation, hot keys, replica lag |
| Write heavy / event driven | Lots of writes, work happens async, reads are aggregates | At-least-once vs exactly-once, partition keys and ordering, back pressure, DLQs, replay |
| Real time fanout | One event must reach many clients within seconds | Gateway sharding, per-connection cost vs batching, reconnect history, fallback to polling |
| Batch and analytics | Minutes-to-hours freshness is fine; queries scan a lot | Batch size vs frequency, Lambda vs Kappa, late data, cost per query |
| Search and filtering | Text, tags and filters; relevance matters as much as speed | Index freshness, typo tolerance, shard/replica scaling, ranking signals |
| File and media | Large blobs, CDN, thumbnails or transcoding | Metadata vs blob split, cold tiers, resumable uploads, signed URLs |
| Workflow orchestration | Multi-step flows that need retries or compensation | Orchestration vs choreography, where state lives, debugging stuck runs |
| Transactional / financial | Money moves; never lose or duplicate | ACID boundaries, idempotency keys, double-entry ledger, outbox, reconciliation |
| Recommendation | Output is a ranked list with a feedback loop | Candidate generation then ranking, offline vs online, cold start, explore vs exploit |
| Events and notifications | One event becomes messages on many channels | Preferences and suppression, dedup keys, immediate vs digest, provider fallback |
Habits that show up in every pattern
- State where the source of truth lives before talking about caches or replicas.
- Make every retried operation idempotent, and say what the idempotency key protects.
- Keep the online serving path separate from the offline or analytics path.
- Decouple producers from consumers with a log or queue, then talk about lag, back pressure and replay.
- Describe the degraded mode: what the user sees when the fast path fails.
Say it like this
- Before I draw anything, let me label this. Feeds are a read-heavy problem with a fanout component, so I'll lead with caching and how writes reach followers.
- This is really a workflow problem, so I'll sketch it as a state machine first and then decide whether one orchestrator owns it or services choreograph through events.
- Money is moving, so the ledger is the source of truth. Everything else is eventually consistent and we reconcile against it.
Bring it up when they ask
- Design a news feed / URL shortener / notification system / payment flow.
- How would you scale this to 10x?
- Walk me through the trade-offs in your design.
- Tell me about a system you designed. (Name its pattern to frame the story.)
Where it fits
- LaunchDarkly
- Flag evaluation (50T evals/day) is read heavy plus real time fanout: flag changes stream out to every SDK. Experimentation results are the batch and analytics pattern.
- iii
- A workflow and agent engine is the orchestration pattern almost by definition, with an event driven core. Expect questions about durable state, retries and stuck runs.