Common Patterns

Combine the technologies and concepts from earlier posts and you can build almost anything. But under interview time pressure, what wins is recognizing patterns. Spot the pattern a design needs, and you fall back on a known playbook instead of reinventing it live.

Recognizing patterns is often what separates senior engineers from junior ones. A pattern tells you what's interesting and what's not, and surfaces failure modes before you hit them. Interviewers aren't grading how many boxes you draw — they're grading whether you name the shape of the problem early and spend the clock on the hard edges.

These patterns aren't mutually exclusive — most designs use several at once. Skim this map first, then jump to the section you need.

Before you draw, listen for requirement keywords and map them to a pattern. This is the 60-second skill that separates "I know Redis" from "I know what problem Redis solves here."

Why this checklist matters: interviewers often bury the pattern inside a product story. "Design Instagram Stories" is really large blobs + long-running transcode + scale reads + maybe realtime for views. If you only hear "Instagram," you will invent random microservices. If you hear the checklist triggers, you land on a coalition in under a minute — and the interviewer knows you have judgment.

In many systems, you'll need to make updates to the user in real time. For synchronous APIs, this is as simple as returning a response once the request is completed. For other systems like chat applications, notifications, or live dashboards, you'll need to be able to push updates to the user as they happen.

There are a lot of decisions to make when implementing realtime updates. First, choose a protocol. Simple HTTP polling is simplest; SSE and WebSockets are purpose-built but need infra care. Full deep dive: Real-time updates (two hops, L4/L7, pub/sub vs hash ownership). Also see Networking essentials.

Notice the diagram frames two separate problems. Interviewers love when you split them explicitly:

Protocol comparison (say this in interviews):

For the server side of realtime updates, you again have more options. Pub/Sub services are a common way to decouple the publisher and subscriber (used in WhatsApp-style chat breakdowns), while stateful servers in a consistent hash ring (or similar) can be used when processing is heavier (Google Docs–style collaboration, where each document has an owning server).

Why interviewers push here: the protocol choice is the easy half. The hard half is fan-out and reconnect. If one chat message must reach 1M online clients, a single app process cannot hold 1M sockets and also do business logic. You put a connection gateway tier in front, fan out via pub/sub, and accept that some clients will miss events during a blip — so you need a cursor or last-event-id to catch up. Trade-off: sticky sessions simplify routing but make rolling deploys and autoscaling painful; gateways + pub/sub scale better but add another hop and failure mode. Expect the next probe to be: "What happens when the client reconnects after 30 seconds offline?"

Deep-dive topics interviewers expect:

Many operations in distributed systems take too long for synchronous processing — video encoding, report generation, bulk operations, or any task that takes more than a few seconds. The Managing Long-Running Tasks pattern splits these operations into immediate acknowledgment and background processing.

When users submit heavy tasks, your web server instantly validates the request, pushes a job to a queue (like Redis or Kafka), and returns a job ID within milliseconds. Separate worker processes continuously pull jobs from the queue and execute the actual work. This provides fast user response times, independent scaling of web servers and workers, and fault isolation.

Walk the diagram left to right in an interview:

Why the queue is not free: you now own job state, retries, DLQs, visibility timeouts, and "what if the worker dies mid-job." Sync keeps back-pressure natural — if the server is overloaded, clients wait or get 503. Async hides overload until the queue length explodes and users see "still processing" forever. Interviewers probe next on idempotency (same job twice), poison messages (always fail), and whether status lives in the queue (bad) or a durable DB (good). Trade-off in one line: queues buy UX and scale isolation; they cost operational surface area.

The key technologies are message queues for job coordination and worker pools for processing. You'll need to handle:

When NOT to use this pattern: login, payment authorization confirmation the user is staring at, anything under ~1–2 seconds where UX is worse with a spinner + poll loop. Sync is simpler and often correct.

Related reading: Message queues for delivery semantics (at-least-once vs exactly-once). Full deep dive: Managing long-running tasks.

When multiple users try to access the same resource simultaneously — like booking the last concert ticket or bidding on an auction item — you need mechanisms to prevent race conditions and ensure data consistency. This pattern addresses coordination challenges in distributed systems.

In the diagram, Alice and Bob both believe they got the last seat because their read–modify–write steps interleaved. Walk this failure mode before proposing a fix — it shows you understand the bug, not just the buzzwords.

Solution ladder (start at the bottom):

Trade-offs include performance versus consistency, and simple database solutions versus complex distributed coordination. Most problems start with single-database solutions before scaling to distributed approaches.

Why "just use Redis lock" is a junior reflex: a distributed lock does not magically fix payment + inventory spanning two services, and holding a lock across a 30-second payment call creates timeouts and deadlocks under load. Prefer a short reservation (seat held for 2 minutes with a TTL) plus a conditional commit when payment succeeds. Interviewers probe next: payment succeeds but seat update fails; replica lag shows stale "available"; and whether eventual consistency is acceptable for inventory displays (often yes) vs checkout (usually no). Name what you are giving up before you split data across systems — that is the senior signal.

Deep-dive prompts to prepare for:

Full deep dive: Dealing with contention (conditional writes, FOR UPDATE, OCC, write skew, distributed leases, deadlocks & ABA). Related: CAP theorem · Consistency models.

As your application grows from hundreds to millions of users, read traffic often becomes the first bottleneck. While writes create data, reads consume it — and read traffic typically grows much faster than write traffic. The Scaling Reads pattern addresses high-volume read requests through database optimization, horizontal scaling, and intelligent caching.

For most applications, the read-to-write ratio starts at 10:1 but often reaches 100:1 or higher. Consider Instagram: when you open the app, you see dozens of photos requiring hundreds of database queries for metadata, user info, and engagement data. Meanwhile, you might only post once per day — a single write operation.

The diagram shows the classic cache-aside read path: (1) check cache first, (2) check DB on cache miss. In an interview, expand that into the full progression:

Key considerations (these are the deep dives):

Why this order exists: each step buys you a different kind of relief and costs a different kind of correctness. Indexes are almost free correctness-wise. Replicas introduce lag — the classic "I just posted and don't see it" bug — so you need read-your-writes for that session. Cache introduces invalidation and stampede risk. CDN is farthest from truth and best for public, slowly changing bytes. Interviewers probe next on hot keys (one viral post), stampede after TTL expiry, and whether you invalidate on write or only rely on TTL. If you cannot explain invalidation, you are not ready to draw Redis.

Full deep dive: Scaling reads (indexes → replicas → Redis → CDN, hot keys, stampede, versioning). Also: Caching strategies · Database indexing.

As your application grows from hundreds to millions of writes per second, individual database servers and storage systems hit hard limits. The Scaling Writes pattern addresses write bottlenecks through sharding, batching, and intelligent load management.

The core strategies are horizontal sharding (distributing data across multiple servers), vertical partitioning (separating different types of data), and handling write bursts through queues and load shedding. Key considerations include selecting good partition keys that distribute load evenly while keeping related data together.

For burst handling, you can use write queues to buffer temporary spikes or implement load shedding to prioritize important writes during overload. Batching techniques help reduce per-operation overhead by grouping multiple writes together.

The diagram is the interview punchline. Good key: hash(UserID) spreads writes evenly under server capacity. Bad key: Country puts China on one shard that blows past capacity while New Zealand idles. Same idea applies to sharding on created_at day — today's shard melts during a festival sale.

How to choose a shard key (checklist):

Cross-shard pain you should name: secondary indexes, unique constraints, transactions across shards, rebalancing when a shard grows. Interviewers respect candidates who admit these costs before proposing 64 shards.

Why sharding early is a trap: you trade one hard problem (one busy primary) for many harder ones (routing, rebalancing, cross-shard joins, dual writes during migration). Queues and batching often buy months of runway without that tax. Interviewers probe next on celebrity hotspots (one user_id owns too much write traffic), how you reshard online, and whether your common query becomes scatter-gather across all shards. If the answer to "what's your shard key?" is vague, pause — the key choice is the design.

Full deep dive: Scaling writes (vertical + DB choice → shard/partition → queues & shedding → batching / hierarchy). Also: Sharding · Scalability · Kafka.

Large files like videos, images, and documents need special handling in distributed systems. Instead of routing gigabytes through your application servers, this pattern uses direct client-to-storage transfers with presigned URLs and CDN delivery.

Your application server generates temporary, scoped credentials (presigned URLs) that let clients upload directly to blob storage like S3. Downloads come from CDNs with signed URLs for access control. This eliminates your servers as bottlenecks while providing resumable uploads, progress tracking, and global distribution.

Walk the diagram in two phases:

Key challenges include:

Why direct-to-storage wins: pushing a 2GB wedding video through your app servers burns CPU, memory, and connection slots that should serve API traffic. The trade-off is consistency between "object exists in S3" and "row exists in DB" — clients can abort mid-upload, leaving orphans, or succeed in S3 while your DB write fails. Solve with multipart uploads, lifecycle rules for incomplete parts, and an event (ObjectCreated) that drives your state machine. Interviewers probe next on access control (never public buckets by default), resumable uploads on flaky mobile networks, and the coalition with long-running tasks for transcoding.

Interview combo: Large Blobs often pairs with Managing long-running tasks (transcode after upload) and Real-time updates (progress %). Name that coalition early. Full deep dive: Handling large blobs.

Complex business processes often involve multiple services and long-running operations that must survive failures, retries, and external dependencies. This pattern provides reliable coordination for workflows like order fulfillment, user onboarding, or payment processing.

Solutions range from simple single-server orchestration to sophisticated workflow engines and durable execution systems. Event sourcing provides a distributed approach where each step emits events that trigger subsequent steps. Modern workflow systems like Temporal or AWS Step Functions handle state management, failure recovery, and retry logic automatically.

The diagram shows an event-driven choreography style:

The key insight is moving from scattered state management and manual error handling to declarative workflow definitions where the system guarantees execution semantics and maintains complete audit trails.

Why scattered if/else fails at scale: each service has partial knowledge, failures leave the system in undefined states, and nobody can answer "where is order 42 stuck?" Orchestration costs a central workflow dependency but gives you visibility and retries in one place. Choreography scales teams independently but makes the full story hard to debug — interviewers love asking you to narrate a failure mid-flow. Trade-off: start with a state machine table in one service; graduate to Temporal/Step Functions when you need durable timers, human approvals, or multi-day waits. Next probe: "Payment charged, restaurant rejected — walk me through compensation."

Several systems like Design Uber or Design Gopuff will require you to search for entities by location. Geospatial indexes are the key to efficiently querying and retrieving entities based on geographical proximity.

These services often rely on extensions to commodity databases like PostgreSQL with PostGIS, Redis geospatial data types, or dedicated solutions like Elasticsearch with geo-queries enabled. Deep dive on trees vs encoded keys: Proximity search.

The architecture typically involves dividing the geographical area into manageable regions and indexing entities within these regions. This allows the system to quickly exclude vast areas that don't contain relevant entities, thereby reducing the search space significantly.

Why region-first matters: a global geo index sounds impressive and is almost always the wrong default. Most queries are local, and location writes from drivers are high-churn — you need a write path that can absorb frequent pings without melting a single store. Trade-off: coarser cells mean more false positives you filter in memory; finer cells mean more neighbor lookups at cell boundaries. Interviewers probe next on ping frequency vs battery, how you expire stale drivers, matching latency under surge, and whether you need a purpose-built index at all for ~1,000 entities (usually no — scan is fine).

Note that most systems won't require users to be querying globally. Often, when proximity is involved, it means users are looking for entities local to them.

Interview deep dives: how often do drivers ping location? How do you avoid stale positions? How do you pick the nearest N available drivers without sorting the entire city every time?

These patterns often work together to solve complex system design challenges. A video platform might use Large Blobs for video uploads, Long-Running Tasks for transcoding, Realtime Updates for progress notifications, and Multi-Step Processes to coordinate the entire workflow.

More coalitions you'll see constantly:

The key is recognizing which patterns apply and understanding their trade-offs. Start simple (polling, one DB, single orchestrator) and only add complexity when requirements demand it.

Next: apply these on URL shortener, News feed, and Rate limiter — and name the patterns as you use them.

Pattern ↔ classic question map

Failure modes to mention

Call out at least one dependency failure (DB down, cache stampede, queue lag, region outage) and your mitigation (timeouts, retries with jitter, degraded mode, circuit breaker).

Practice saying these out loud for common system design patterns. Interviewers grade clarity and judgment more than buzzwords.