Common Patterns Overview

Patterns are reusable responses to recurring constraints. Their names are useful only when paired with trigger conditions, state ownership, and a failure path. This page maps the seven pattern chapters to the question they help answer, then gives a compact selection method.

The mechanism at a glance

Figure — User request → Pattern trigger (identify constraint); Pattern trigger → State owner (choose narrow pattern); State owner → Async work (durable handoff); Async work → Client update (progress/resume); Async work → Recovery (retry or reconcile)

The numbered components identify responsibilities. Follow the labeled arrows rather than treating the numbers as a global execution order. The scenario later in this lesson shows one concrete sequence.

Step-by-step reasoning

1. 1 · Frame

Real-time Updates chooses how clients receive changes and resume after disconnect. Dealing with Contention protects a scarce or conflicting state transition. Multi-step Processes handles a workflow spanning durable steps. Start by naming whether the problem is delivery, conflict, or coordination.

2. 2 · Model

Scaling Reads covers replicas, caches, and materialized projections. Scaling Writes covers buffering, batching, and partitioning. Handling Large Blobs separates metadata from bulk transfer. Managing Long Running Tasks persists leases, heartbeats, checkpoints, and cancellation. Each requires a different durable boundary.

3. 3 · Scale

Select the smallest pattern that fixes a measured need. Write down the state owner, idempotency key, ordering scope, backlog or freshness limit, and recovery action. Then apply the pattern to a course case such as WhatsApp, Ticketmaster, Payment System, Dropbox, or LeetCode.

4. 4 · Recover

Patterns compose, but each adds operational work. A queue can absorb a write burst, yet it cannot increase sustainable downstream capacity by itself. A cache can reduce reads, yet it needs invalidation or freshness rules. A workflow engine can persist steps, yet business effects still need idempotency.

Contracts and state

The following sketch makes the decision boundary concrete. Field names and capacity assumptions are illustrative; adapt them to the stated product contract.

Trigger -> pattern -> authoritative state -> retry identity -> overload/failure behavior
Delivery: push/poll + resume
Conflict: conditional write/lock/queue
Workflow: durable state machine + compensation
Scale: bounded queues, projections, blob transfer, task leases

Worked example

A video upload has a large object and a long-running transcode. Handling Large Blobs separates multipart transfer from metadata; Managing Long Running Tasks records transcode state and retries; Real-time Updates reports progress. Their boundaries remain distinct: upload completion does not mean encoding completed.

Failure walkthrough

A team adds a queue to a dependency already processing below arrival rate. Queue depth grows without bound. Scaling Writes only smooths bursts; add capacity, apply admission control, or reduce work until service rate can exceed arrivals over the recovery period.

Figure — Constraint is identified → Pattern is matched to it → State owner and identity are defined → Failure or overload is tested → Recovery stays bounded

Decisions and trade-offs

Check your understanding

Choose two patterns for a media upload that creates a long-running encode and sends progress to a client. Identify which state each owns.

Open a chapter

• Real-time Updates
• Dealing with Contention
• Multi-step Processes
• Scaling Reads
• Scaling Writes
• Handling Large Blobs
• Managing Long Running Tasks