Closing thoughts on the 15 examples
Patterns recur across the 15 problems:
| Pattern | Appears in | What it solves |
|---|---|---|
| Hot keys / celebrity problem | Twitter, Instagram, YouTube, Slack, distributed cache | Long-tail distribution of access; need special path for outliers |
| Push vs pull (write-time vs read-time work) | Twitter, Instagram, notification service, Slack | Tradeoff between read latency and write cost |
| Multi-tier caching | Twitter, YouTube, URL shortener, Instagram, distributed cache | Performance at scale; absorb hot reads at each tier |
| Async via queues (Kafka, SQS) | Every problem with fan-out or slow downstream | Decoupling; backpressure; retry tolerance |
| Idempotency | Payments, scheduler, notifications, webhook delivery | Safe retries; correct semantics under failure |
| Sharding by some key | Almost every problem | Horizontal scaling; isolate failure domains |
| Consistent hashing | Distributed cache, KV stores, location services | Stable distribution under topology changes |
| Content addressing | Dropbox, Git, Docker images, S3 | Dedup; immutable units of work |
| Lease-based ownership | Scheduler, distributed locks, leader election | Failure-tolerant exclusive access |
| Append-only ledgers | Payments, audit logs, event sourcing | Correctness; auditability; no mutation bugs |
| CDN + edge caching | YouTube, Instagram, URL shortener, static content | Latency reduction; bandwidth cost optimization |
| WebSocket gateway tier | WhatsApp, Slack, Dropbox sync, presence | Long-lived connection management at scale |
These patterns aren't independent. They appear together because they solve the same fundamental tensions: distributing work across many machines, dealing with skewed traffic, handling failures, and keeping latency low. Internalize the patterns, and any new system design problem becomes recognizable.
The senior engineer's edge isn't knowing more topics. It's recognizing patterns faster. After studying these 15, when you encounter an unfamiliar problem, your brain pattern-matches: "this is like Twitter's feed but with X different" or "this is like the URL shortener but the keys are different." From there, you apply the templates and focus on what's actually novel. That's how you move from "I remember solutions" to "I can design from first principles."
How to actually internalise these patterns
- Try each on a blank page first. Spend 15-20 minutes designing before reading the walkthrough. Compare.
- Identify your gaps. Were you missing the celebrity problem? Did you forget idempotency? Did you skip the failure mode analysis? These are your weakest areas.
- Re-read the chapters that explain those concepts. The cross-references are deliberate — every example uses concepts from the earlier chapters.
- Design something for your day job. Take a real internal system at your company, work through its design as if you were interviewing about it. You'll discover questions you'd never asked.
- Read public engineering blog posts on these systems (Twitter, Slack, Discord, Dropbox, Stripe have all published architecture details). Compare with your design. See where reality diverges from textbook.
The patterns become muscle memory after enough repetition. Then the next system you encounter — at work, at interview, in real life — feels manageable because you've seen the shape of it before.