Pattern to Question Bridge
TL;DR
This course taught you the building blocks — caching, sharding, locking, WebSockets, queues, sagas, presigned URLs. The Question Breakdowns course teaches you how to assemble them into complete system designs. This lesson is the bridge: a mapping from every pattern to the interview questions where that pattern is the critical insight.
The Bridge Table
Every pattern you learned solves a specific class of problems. The table below maps each pattern to the interview questions where it's the difference between a mediocre answer and a strong one.
| Pattern (Chapter) | Key In These Questions | Why This Pattern Is Critical |
|---|---|---|
| Scaling Reads (Ch. 1) | Bit.ly, Instagram, FB News Feed, FB Post Search, Yelp, YouTube, Distributed Cache, News Aggregator, Price Tracking Service | Read-to-write ratio is 100:1+. Without caching + CDN + read replicas, the system falls over under read load. FB Post Search is a read optimization problem — search indexing (inverted index, Elasticsearch) is how you scale reads for text queries. Note: Yelp also requires geospatial indexing (QuadTree/Geohash) for location-based queries — a pattern covered in specialized data structures, not this course. |
| Scaling Writes (Ch. 2) | YouTube Top K, Strava, Ad Click Aggregator, Metrics Monitoring, Rate Limiter | Write volume is the bottleneck. Raw inserts won't keep up — you need batching, pre-aggregation, sharded writes, or LSM-based storage. |
| Concurrency Control (Ch. 3) | Ticketmaster, Online Auction, Robinhood, Rate Limiter | Multiple users competing for the same resource at the same time. Without proper locking or reservation patterns, you get overselling, double-spending, or race conditions. |
| Push Architectures (Ch. 4) | WhatsApp, FB Live Comments, Google Docs, Tinder | Real-time delivery is a core requirement. Polling won't cut it — you need WebSocket or SSE with fan-out infrastructure. |
| Async Processing (Ch. 5) | Instagram, YouTube, LeetCode, Job Scheduler, Web Crawler | Processing takes seconds to hours. Blocking the user while a video transcodes or a crawler runs is not an option. Queue + workers + progress tracking. |
| Distributed Workflows (Ch. 6) | Uber, Payment System, Robinhood, Local Delivery Service | Multi-step operations spanning multiple services. A crash mid-workflow must not leave the system in an inconsistent state. Sagas, idempotency, compensation. Note: Uber also requires geospatial indexing (QuadTree/Geohash) for proximity-based driver matching — a pattern covered in specialized data structures, not this course. |
| Large Files (Ch. 7) | Dropbox, YouTube, Instagram | Files measured in megabytes or gigabytes. Direct upload through your API server is a non-starter. Presigned URLs, chunking, CDN delivery. |
How to Use This in an Interview
The bridge works in one direction during the interview: requirements → signals → patterns → techniques.
Step 1: Read the requirements. Spot the signals.
The interviewer says "Design Instagram." You hear:
- Users scroll a feed of images → read-heavy (100:1 ratio)
- Users upload photos → large files (images are 1–10MB)
- Photos need filters and multiple resolutions → async processing (image pipeline)
- Feed includes posts from people you follow → fan-out (write or read)
Step 2: Name the patterns out loud.
"This is a read-heavy system — the feed is consumed far more than it's written to. I'll use caching and CDN for the read path. Uploads involve large files, so I'll use presigned URLs to S3. Image processing is async — I'll queue it and process with workers."
Naming patterns does two things: it shows the interviewer you have a framework, and it gives you a roadmap for the next 30 minutes.
Step 3: Apply techniques from the relevant chapters.
Each chapter gave you specific techniques. Pull them in:
- Scaling Reads → Cache-aside for feed data, CDN for images, read replicas for profile queries
- Large Files → Presigned URL upload to S3, client-side image validation
- Async Processing → SQS queue triggers Lambda/workers for resize + filter pipeline
- Scaling Writes → Fan-out-on-write for small follower counts, fan-out-on-read for celebrities
Step 4: The Question Breakdown shows the full assembly.
The Question Breakdowns course takes these same patterns and shows how they wire together into a complete design with API contracts, data models, and scaling analysis. This course gave you the vocabulary. That course gives you the fluency.
Common Multi-Pattern Combinations
Real interview questions never test a single pattern. They combine two, three, or four patterns — and the strong candidates identify all of them.
Design Instagram
| Concern | Pattern | Technique |
|---|---|---|
| Feed reads (100:1 ratio) | Scaling Reads | CDN for images, Redis cache for feed, read replicas |
| Image uploads | Large Files | Presigned URL → S3, client-side validation |
| Image processing | Async Processing | Queue → workers for resize, filter, thumbnail |
| Feed generation | Scaling Writes (fan-out) | Fan-out-on-write for normal users, fan-out-on-read for celebrities |
| Notifications | Push Architecture | Push notification service, async delivery |
Design Uber
| Concern | Pattern | Technique |
|---|---|---|
| Live driver locations | Push Architecture | WebSocket for rider app, driver pings every 3–5s |
| Driver matching | Concurrency Control | Optimistic lock on driver availability, geospatial index |
| Ride lifecycle | Distributed Workflows | Saga: request → match → pickup → trip → payment → complete |
| Surge pricing | Scaling Writes | Real-time aggregation of demand per region |
| Trip history | Scaling Reads | Cache recent trips, read replicas for historical |
Design Ticketmaster
| Concern | Pattern | Technique |
|---|---|---|
| Event browsing | Scaling Reads | CDN for event pages, Redis for seat maps |
| Seat reservation | Concurrency Control | Pessimistic lock (SELECT FOR UPDATE) or reservation with TTL |
| High-demand on-sale | Async Processing | Virtual queue + admission control |
| Payment flow | Distributed Workflows | Saga: reserve → charge → confirm (compensate on failure) |
| Inventory updates | Push Architecture | SSE to update seat map in real-time |
Design YouTube
| Concern | Pattern | Technique |
|---|---|---|
| Video upload | Large Files | Chunked upload with resume, presigned URLs to object storage |
| Transcoding | Async Processing | Queue → transcoding workers → multiple resolutions |
| Video streaming | Scaling Reads | CDN at edge, adaptive bitrate streaming (HLS/DASH) |
| View counting | Scaling Writes | Batch + aggregate, eventual consistency on counts |
| Comments/reactions | Push Architecture | WebSocket or SSE for live comments during premiere |
Design WhatsApp
| Concern | Pattern | Technique |
|---|---|---|
| Message delivery | Push Architecture | WebSocket per device, connection registry |
| Offline delivery | Async Processing | Queue messages per user, deliver on reconnect |
| Group messages | Push Architecture (fan-out) | Fan-out to group members via pub/sub |
| Media sharing | Large Files | Presigned URL upload, CDN delivery, auto-expiry |
| Read receipts | Push Architecture | Lightweight WebSocket event, eventual delivery |
Design a Payment System
| Concern | Pattern | Technique |
|---|---|---|
| Transaction processing | Distributed Workflows | Saga: authorize → capture → settle (compensate: refund) |
| Idempotency | Distributed Workflows | Idempotency key per request, dedup table |
| Balance checks | Concurrency Control | Pessimistic lock on account balance during debit |
| Transaction history | Scaling Reads | Read replicas, cache recent transactions |
| Webhook delivery | Async Processing | Queue + retry with exponential backoff |
The Signal Detection Checklist
Use this as a mental checklist when the interviewer finishes describing the system.
| Question to Ask Yourself | If Yes → | Chapter |
|---|---|---|
| Is the read:write ratio > 10:1? | Caching, CDN, read replicas | Ch. 1 |
| Are writes > 10K/sec? | Sharding, batching, LSM storage | Ch. 2 |
| Can two users modify the same thing simultaneously? | Locking, OCC, reservations | Ch. 3 |
| Do users need to see updates without refreshing? | WebSocket, SSE, pub/sub | Ch. 4 |
| Does any operation take > 5 seconds? | Queue, workers, job tracking | Ch. 5 |
| Does the workflow span multiple services? | Saga, idempotency, compensation | Ch. 6 |
| Are files > 1MB involved? | Presigned URLs, chunking, CDN | Ch. 7 |
If you answer "no" to all of these, you're probably looking at a straightforward CRUD application — and the interview is testing something else (data modeling, API design, or access patterns).
Patterns That Pair Together
Some patterns almost always appear together. If you use one, expect to need the other.
| If You Use... | You'll Probably Also Need... | Why |
|---|---|---|
| Async Processing | Push Architecture | Users need to know when the job finishes |
| Large Files | Async Processing | Processing large files (transcode, resize) is never instant |
| Distributed Workflows | Concurrency Control | Saga steps often involve shared resources |
| Scaling Writes | Scaling Reads | High-write systems still need to serve the aggregated data |
| Concurrency Control | Async Processing | Overflow traffic goes into a waiting queue |
What This Course Did Not Cover
This course focused on architecture patterns — the recurring structural solutions to system design problems. It intentionally did not cover:
- API design — endpoint naming, pagination, versioning, rate limiting contracts
- Data modeling — schema design, normalization vs. denormalization, access pattern analysis
- Networking fundamentals — DNS, TCP/UDP, TLS, HTTP/2, gRPC
Those are covered in their own courses. Architecture patterns assume you already know how to design an API and model your data. They sit one level above, answering: "Given the data model and APIs, how do I build a system that handles the load, maintains consistency, and stays responsive?"
The One-Page Summary
┌─────────────────────────────────────────────────────────┐
│ ARCHITECTURE PATTERNS │
│ │
│ Signal → Pattern │
│ ────────────────────────────────────────────────────── │
│ Read-heavy → Cache + Replicas + CDN │
│ Write-heavy → Shard + Batch + LSM │
│ Contention → Lock + Reserve + Retry │
│ Real-time → WebSocket + SSE + Fan-out │
│ Slow operations → Queue + Workers + Progress │
│ Multi-service → Saga + Idempotency + Compensate │
│ Large files → Presigned + Chunk + CDN │
│ │
│ Spot the signal. Name the pattern. Apply the technique. │
│ The Question Breakdowns show the full assembly. │
└─────────────────────────────────────────────────────────┘
You now have the building blocks. The Question Breakdowns course shows you how to assemble them into complete system designs.