A visual catalog of the patterns senior engineers reach for—not definitions, but when to use each, what it costs, and where you've seen it in production. Organized by category for quick lookup during mock interviews and design reviews. Pair with Interview Framework for structured delivery.
Handle growth in users, traffic, and data volume without redesigning from scratch.
Problem · Read/write asymmetry
Solution: Separate command (write) and query (read) models; writes go to OLTP, reads served from denormalized projections.
Trade-off: Eventual consistency on read side; dual-model maintenance and sync pipeline complexity.
Real-world: Microsoft Azure uses CQRS in event-sourced order processing; read models rebuilt from event log.
Problem · Audit trail + temporal queries
Solution: Persist state changes as immutable events; current state derived by replaying event stream.
Trade-off: Storage grows unbounded; snapshotting required; replay latency for cold aggregates.
Real-world: LMAX exchange processes billions of trades via event sourcing with in-memory replay.
Problem · Dataset exceeds single-node capacity
Solution: Horizontally split data by shard key (user_id, tenant_id); route queries to correct shard.
Trade-off: Cross-shard queries expensive; hot shards; resharding is painful without consistent hashing.
Real-world: Instagram shards user data by user_id; Twitter shards tweets by tweet_id across thousands of nodes.
Problem · Uneven key distribution on ring
Solution: Map keys and nodes to hash ring; each key owned by next clockwise node; virtual nodes for balance.
Trade-off: Still possible hot spots; range queries unsupported; more complex than modulo hashing.
Real-world: Amazon DynamoDB and Cassandra use consistent hashing for partition placement.
Problem · Expensive read path on every request
Solution: Precompute join results into read-optimized tables or documents updated on write or via CDC.
Trade-off: Write amplification; stale reads unless sync is tight; schema duplication.
Real-world: Facebook TAO materializes social graph edges for sub-ms friend-list reads.
Problem · Celebrity traffic spikes
Solution: On tweet/post, push to all follower feeds at write time; reads are O(1) cache lookup.
Trade-off: Write amplification for users with millions of followers; Katy Perry problem.
Real-world: Twitter hybrid: fan-out on write for normal users, fan-out on read for celebrities.
Problem · Millions of followers, write amplification
Solution: Store posts in author timeline; merge follower timelines at read time.
Trade-off: Read latency grows with follower count; complex pagination.
Real-world: Twitter uses fan-out on read for accounts with >1M followers.
Problem · Mixed follower distribution
Solution: Fan-out on write below threshold; fan-out on read above; tiered by follower count.
Trade-off: Two code paths to maintain; threshold tuning per product.
Real-world: Twitter's famous hybrid model documented in their engineering blog.
Problem · Traffic exceeds single server
Solution: Add stateless app servers behind load balancer; partition stateful tiers separately.
Trade-off: Requires shared-nothing or externalized state; session stickiness pitfalls.
Real-world: Netflix scales API tiers horizontally; state lives in Cassandra and EVCache.
Problem · Predictable traffic bursts
Solution: Scale instance count on CPU, QPS, or queue depth metrics with cooldown periods.
Trade-off: Cold start latency; over-provisioning cost; scale-down too aggressive causes flapping.
Real-world: AWS Auto Scaling Groups behind ALB for Black Friday e-commerce peaks.
Problem · Global users, latency
Solution: Deploy data and compute in regional cells; route users to nearest region.
Trade-off: Cross-region consistency hard; data residency compliance; operational complexity.
Real-world: Google Spanner multi-region with TrueTime; Uber geo-partitions ride data.
Problem · Read-heavy, write-rare
Solution: Primary handles writes; N replicas serve read traffic with async replication lag.
Trade-off: Replication lag causes stale reads; failover promotion complexity.
Real-world: PostgreSQL read replicas on AWS RDS for analytics queries off primary.
Survive partial failures, prevent cascades, and recover gracefully.
Problem · Downstream dependency failures cascade
Solution: Track failure rate; open circuit after threshold; fail fast with fallback; half-open probe.
Trade-off: Tuning thresholds is hard; false opens under transient blips; needs metrics.
Real-world: Netflix Hystrix (now resilience4j) protects microservice chains from cascade failures.
Problem · One bad tenant consumes all resources
Solution: Isolate thread pools, connection pools, or queues per tenant/service so failure is contained.
Trade-off: Lower overall utilization; more infrastructure to provision per bulkhead.
Real-world: Hystrix thread pools per dependency; Kubernetes resource quotas per namespace.
Problem · Transient network / service errors
Solution: Retry failed calls with increasing delay and jitter; cap max attempts.
Trade-off: Thundering herd if all clients retry simultaneously; idempotency required.
Real-world: AWS SDK built-in retry with jitter for S3 and DynamoDB API calls.
Problem · Duplicate requests cause double-charge
Solution: Client sends unique idempotency key; server stores result keyed by key for replay window.
Trade-off: Storage for idempotency records; TTL management; key collision handling.
Real-world: Stripe API requires Idempotency-Key header on all POST requests.
Problem · Partial failure in multi-step workflow
Solution: Each step has undo operation; on failure, run compensations in reverse order.
Trade-off: Not all operations are reversible; saga orchestration complexity.
Real-world: Airline booking: cancel seat reservation if payment fails.
Problem · Service unavailable, must degrade
Solution: Serve cached/stale data or reduced feature set when dependencies fail.
Trade-off: User sees degraded UX; must define acceptable degradation levels.
Real-world: Netflix serves stale recommendations when personalization service is down.
Problem · Unknown failure state after timeout
Solution: On timeout or error, return safe default rather than error or stale critical data.
Trade-off: May hide real problems; defaults must be product-acceptable.
Real-world: Rate limiter fails open vs closed depending on abuse risk tolerance.
Problem · Process crash loses in-flight work
Solution: Periodically persist processing state so restart resumes from last checkpoint.
Trade-off: Checkpoint frequency vs recovery granularity trade-off; storage cost.
Real-world: Kafka consumer offsets as checkpoints; Flink savepoints for stream jobs.
Problem · Need 99.99% despite component failures
Solution: Deploy N+1 or active-active across AZs; health checks trigger failover.
Trade-off: Cost doubles or more; split-brain risk without proper fencing.
Real-world: RDS Multi-AZ automatic failover; Kubernetes pod anti-affinity across nodes.
Problem · Detect failures quickly
Solution: Liveness/readiness probes; periodic heartbeats with timeout-based failure detection.
Trade-off: False positives from GC pauses; phi-accrual improves on fixed timeouts.
Real-world: Kubernetes liveness probes; Consul health checks for service mesh.
Problem · Chaos validation
Solution: Deliberately inject latency, errors, and kills in staging/prod to validate resilience.
Trade-off: Risk in production without blast-radius controls; requires mature observability.
Real-world: Netflix Chaos Monkey randomly terminates instances in production.
Problem · Overload causes total collapse
Solution: Drop or reject low-priority requests when saturation detected to protect core path.
Trade-off: Dropped requests = errors for some users; priority classification needed.
Real-world: Google SRE practice: return 503 early rather than queue infinitely.
Consistency, caching, replication, and integrity across distributed data stores.
Problem · Dual-write DB + queue race condition
Solution: Write business row + outbox row in same DB transaction; relay publishes outbox to queue.
Trade-off: Relay lag; at-least-once delivery requires consumer idempotency.
Real-world: Debezium CDC from outbox table; Uber uses outbox for reliable event publishing.
Problem · Distributed transaction across services
Solution: Central orchestrator coordinates local transactions with compensating steps on failure.
Trade-off: Orchestrator SPOF unless HA; complex state machine; debugging distributed flows.
Real-world: Uber's Cadence/Temporal workflows for multi-step ride and payment sagas.
Problem · Distributed transaction, choreography
Solution: Services publish events; each reacts and publishes next step; no central coordinator.
Trade-off: Hard to trace; cyclic dependencies; compensations harder to reason about.
Real-world: Microservices order flow: Order → Payment → Inventory via domain events.
Problem · Cache and DB out of sync
Solution: App reads cache first; on miss, read DB and populate cache; writes update DB then invalidate cache.
Trade-off: Cache stampede on miss; thundering herd after invalidation.
Real-world: Redis cache-aside for product catalog at most e-commerce sites.
Problem · Write-heavy, read from same path
Solution: App writes to cache; cache synchronously writes to DB before acknowledging.
Trade-off: Write latency includes cache + DB; cache becomes write bottleneck.
Real-world: CDN edge write-through for user-uploaded assets with origin sync.
Problem · DB change must invalidate cache
Solution: Stream DB WAL/binlog changes to consumers for cache invalidation or search index sync.
Trade-off: Ordering guarantees per partition; schema evolution; lag monitoring.
Real-world: LinkedIn Databus; Debezium streaming PostgreSQL WAL to Kafka.
Problem · Hot key overloads single partition
Solution: Append random salt to hot keys to spread writes across partitions; merge on read.
Trade-off: Read path must aggregate salted shards; application complexity.
Real-world: YouTube view counts split across multiple counter shards.
Problem · Need approximate counts at scale
Solution: HyperLogLog for cardinality, Count-Min Sketch for frequency, Bloom filter for membership.
Trade-off: Approximate only; tuning parameters; not suitable for exact financial data.
Real-world: Redis HyperLogLog for unique visitor counts; Cassandra Bloom filters on SSTables.
Problem · Multi-master write conflicts
Solution: Resolve conflicts by timestamp; latest write wins across replicas.
Trade-off: Clock skew causes data loss; not suitable for counters or collaborative edits.
Real-world: DynamoDB and Cassandra default conflict resolution for concurrent puts.
Problem · Collaborative editing without locks
Solution: Conflict-free replicated data types merge concurrent updates deterministically.
Trade-off: Limited to specific data types; memory overhead; garbage collection of tombstones.
Real-world: Figma uses CRDTs for real-time collaborative design document sync.
Problem · Strong ordering in distributed log
Solution: One leader accepts writes; followers replicate log; reads from leader or followers.
Trade-off: Leader bottleneck; failover election window; AZ failure risk.
Real-world: PostgreSQL streaming replication; Kafka partition leader.
Problem · High write availability multi-region
Solution: Writes go to W nodes; reads from R nodes where W+R>N for overlap consistency.
Trade-off: Conflict resolution on concurrent writes; read repair complexity.
Real-world: Cassandra QUORUM reads/writes; DynamoDB with N=3, W=2, R=2.
Async communication, ordering, delivery guarantees, and event-driven architecture.
Problem · Async decoupling of producers/consumers
Solution: Producer sends to queue; one consumer processes each message; ack deletes.
Trade-off: No replay without DLQ; ordering only per partition; backpressure management.
Real-world: AWS SQS for order processing workers; RabbitMQ task queues.
Problem · Multiple subscribers, event broadcast
Solution: Publisher sends to topic; all subscribers receive copy; decoupled fan-out.
Trade-off: Subscriber slow → backlog; need retention policy; ordering per partition only.
Real-world: Google Pub/Sub; Kafka topics with multiple consumer groups.
Problem · Event log with replay
Solution: Durable ordered log; consumers track offset; replay from any point; retention policy.
Trade-off: Operational complexity; partition count planning; exactly-once is hard.
Real-world: LinkedIn Kafka origins; Uber processes 4T+ messages/day on Kafka.
Problem · Guaranteed processing despite failures
Solution: Ack after processing; retry on failure; consumer deduplicates by message ID.
Trade-off: Duplicate processing window; idempotency store overhead.
Real-world: Payment processors dedupe by transaction_id on Kafka consumer replay.
Problem · No duplicate processing ever
Solution: Transactional producer + idempotent consumer + offset commit in same transaction.
Trade-off: Performance cost; limited broker support; end-to-end still needs idempotent sinks.
Real-world: Kafka transactions API; Flink exactly-once with checkpointed sinks.
Problem · Poison messages block queue
Solution: After N failed attempts, move message to DLQ for manual inspection and replay.
Trade-off: DLQ monitoring required; replay tooling; alert fatigue if DLQ fills.
Real-world: SQS redrive policy to DLQ after maxReceiveCount exceeded.
Problem · Priority handling under load
Solution: Separate queues or priority levels; high-priority messages processed first.
Trade-off: Starvation of low priority; complexity in routing; monitoring per tier.
Real-world: Hospital triage systems; payment fraud checks on high-priority queue.
Problem · Backpressure when consumer slow
Solution: Track consumer lag metric; auto-scale consumers or throttle producers when lag exceeds SLO.
Trade-off: Scaling consumers has limits (partition count); unbounded lag is data loss risk.
Real-world: Kafka consumer lag alerts in Datadog; K8s HPA on consumer deployment.
Problem · Ordered processing per entity
Solution: Route all events for same entity (user_id) to same partition for FIFO guarantee.
Trade-off: Hot partitions if key distribution skewed; limits parallelism per key.
Real-world: Kafka partition by order_id ensures ordered payment state transitions.
Problem · Schema evolution in events
Solution: Central registry for Avro/Protobuf schemas; compatibility checks on publish.
Trade-off: Operational dependency; breaking schema changes need migration plan.
Real-world: Confluent Schema Registry with BACKWARD compatibility for Kafka producers.
Problem · Request-reply over async bus
Solution: Request includes correlation_id; reply routed back via temporary reply queue or callback.
Trade-off: Timeout handling; orphaned replies; callback endpoint availability.
Real-world: RabbitMQ reply-to header; AWS SNS/SQS request-response with correlation IDs.
Problem · Scheduled / delayed delivery
Solution: Message visible after delay interval; used for retries, reminders, scheduled jobs.
Trade-off: Clock precision; max delay limits; not a cron replacement at scale.
Real-world: SQS delay queues; RabbitMQ delayed message plugin for retry backoff.
Ship safely, roll back fast, and migrate legacy without downtime.
Problem · Zero-downtime releases
Solution: Replace instances incrementally; old and new versions run simultaneously during rollout.
Trade-off: Mixed-version bugs; slow rollback; schema compatibility required.
Real-world: Kubernetes default RollingUpdate strategy for Deployments.
Problem · Instant rollback, two versions live
Solution: Deploy new version (green) alongside old (blue); switch traffic via LB; keep blue for rollback.
Trade-off: Double infrastructure cost during switch; database migration complexity.
Real-world: AWS CodeDeploy blue-green with ALB target group swap.
Problem · Gradual risk reduction
Solution: Route small % of traffic to new version; monitor metrics; incrementally increase.
Trade-off: Metric noise at low traffic; requires automated promotion/rollback.
Real-world: Spinnaker canary analysis; Istio traffic splitting 5% → 25% → 100%.
Problem · Per-user or per-tenant testing
Solution: Runtime config routes users to new features without redeploy; kill switch included.
Trade-off: Flag debt accumulates; testing matrix explosion; needs flag management platform.
Real-world: LaunchDarkly at Netflix; internal flag systems at most FAANG companies.
Problem · Incremental legacy replacement
Solution: New functionality built on new system; proxy routes traffic gradually from monolith.
Trade-off: Long migration timeline; dual maintenance; routing layer complexity.
Real-world: Amazon's gradual extraction of services from original monolithic codebase.
Problem · Immutable infrastructure
Solution: Never patch running servers; replace entire instance/image on every deploy.
Trade-off: Slower deploy if images large; state must be externalized.
Real-world: Docker container replacement; AMIs rebuilt not patched in Netflix OSS.
Problem · Database schema changes safely
Solution: Expand: add new column nullable; migrate data; contract: remove old column in later release.
Trade-off: Requires multiple deploy cycles; application handles both schemas temporarily.
Real-world: Stripe's approach to zero-downtime PostgreSQL migrations.
Problem · Traffic shift for maintenance
Solution: Stop sending new requests to instance; wait for in-flight to complete; then terminate.
Trade-off: Drain timeout must exceed longest request; health check coordination.
Real-world: Kubernetes preStop hook + terminationGracePeriodSeconds for graceful shutdown.
Problem · Multi-environment promotion
Solution: Dev → staging → prod with gates; config differs per env; same artifact promoted.
Trade-off: Staging never matches prod; environment drift; test data gaps.
Real-world: CI/CD pipelines in GitHub Actions with manual prod approval gate.
Problem · Container orchestration at scale
Solution: Declarative desired state; scheduler places pods; self-healing; rolling updates.
Trade-off: Operational learning curve; networking complexity; stateful workload challenges.
Real-world: Spotify, Airbnb, Pinterest run production on Kubernetes.
Problem · Edge traffic management
Solution: Static and cacheable content at edge PoPs; origin shield for collapse protection.
Trade-off: Cache invalidation latency; dynamic content harder; cost at scale.
Real-world: Cloudflare and Akamai serve majority of static web assets globally.
Problem · Infra as versioned code
Solution: Terraform/Pulumi define infra declaratively; plan/apply with review; drift detection.
Trade-off: State file management; module versioning; blast radius of bad apply.
Real-world: All major cloud-native companies manage infra via Terraform or CDK.
Consensus, clocks, failure detection, and coordination at scale.
Problem · Network partition, need consensus
Solution: Leader election + log replication; majority quorum for commit; linearizable writes.
Trade-off: Latency of quorum round; leader bottleneck; not for high-throughput writes.
Real-world: etcd uses Raft; CockroachDB and TiKV built on Raft for distributed SQL.
Problem · Leader election without split-brain
Solution: Candidates compete via ephemeral nodes; fencing tokens prevent stale leader writes.
Trade-off: ZooKeeper operational burden; etcd quorum sizing; watch latency.
Real-world: Kubernetes controller-manager leader election via etcd leases.
Problem · Distributed mutual exclusion
Solution: Acquire lock via Redis SETNX or etcd; fencing token invalidates stale lock holders.
Trade-off: Redlock controversy; lock holder crash leaves lock until TTL; always use fencing.
Real-world: Google Chubby for GFS master election; Martin Kleppmann's fencing token critique.
Problem · Global timestamps without perfect clocks
Solution: Combine physical timestamp with logical counter for causally consistent ordering.
Trade-off: Not true wall-clock; drift handling; not linearizable globally.
Real-world: CockroachDB uses HLC for distributed transaction timestamps.
Problem · True global ordering
Solution: GPS + atomic clocks bound clock uncertainty; commit wait for uncertainty window.
Trade-off: Expensive hardware; ~5-10ms commit wait; not available on commodity cloud.
Real-world: Google Spanner external consistency via TrueTime API.
Problem · Membership and failure detection
Solution: Nodes periodically exchange state; epidemic dissemination; phi-accrual failure detection.
Trade-off: Eventual membership convergence; bandwidth at scale; not for strong consistency.
Real-world: Amazon Dynamo membership; Cassandra gossip for ring state.
Problem · Consistent view of cluster state
Solution: Register services; health check; DNS or sidecar proxy resolves healthy instances.
Trade-off: Cache staleness; split-brain during partition; needs HA for registry itself.
Real-world: Kubernetes DNS + Endpoints; Consul service mesh at HashiCorp deployments.
Problem · Partial failures invisible to client
Solution: Design assuming network is unreliable, latency is non-zero, bandwidth is finite.
Trade-off: Over-engineering if ignored; under-engineering if forgotten.
Real-world: Every senior interview probes whether you account for partial failure.
Problem · Unreliable network, need delivery guarantee
Solution: Choose delivery semantics per use case; financial = exactly-once or idempotent at-least-once.
Trade-off: Exactly-once end-to-end is myth without idempotent sinks; performance trade-offs.
Real-world: Kafka delivery guarantees documented per producer acks and consumer config.
Problem · Clock skew breaks ordering
Solution: Logical clocks establish happened-before without synchronized physical clocks.
Trade-off: Vector clock size grows with replicas; not human-readable timestamps.
Real-world: Dynamo paper uses vector clocks for conflict detection.
Problem · Split brain during partition
Solution: Require majority for writes; fence old leader with generation numbers or STONITH.
Trade-off: Availability loss during partition minority side; operator confusion.
Real-world: MongoDB replica set elections; Redis Sentinel with quorum.
Problem · State machine replication
Solution: All nodes apply same ordered log of commands; deterministic state machine yields same state.
Trade-off: Log compaction needed; snapshot + replay for new nodes; command size limits.
Real-world: Raft replicated state machine pattern in etcd and Consul.
Never name-drop a pattern without stating the problem it solves and its trade-off. "I'd use CQRS because reads are 100× writes and we can denormalize the feed" beats "we'll use CQRS" every time.
