Loading…
Loading…
A pattern is a system shape — read-heavy, write-heavy, fan-out, long-running, real-time. Interviewers recognise these on sight and expect you to pattern-match fast. Each write-up covers when you reach for it, the canonical skeleton, a scaling path, and the failure modes that kill it.
How traffic is distributed between reads and writes drives every other decision.
Use caches, replicas and edge layers to absorb repeated reads before they reach the primary database.
You see it when: The interviewer states or implies a read:write ratio of 10:1, 100:1, or higher
Use logs, shards, batching and idempotent consumers when the write path is the thing that runs out first.
You see it when: Write QPS is 10K+ per region and climbing
Use synchronous HTTP, a small app tier, a database and selective caching when the user needs an answer now.
You see it when: Standard CRUD APIs — user profile, settings, admin consoles
Synchronous, asynchronous, real-time — how work flows through the system.
Return a job id quickly, run the work elsewhere, and expose status, progress, cancellation and results.
You see it when: Processing takes 10 seconds to hours — far longer than HTTP timeout budgets
Put durable work between bursty producers and steady consumers, then make retries, idempotency and backpressure explicit.
You see it when: Synchronous call does work the user does not need to wait on (email send, image resize, index update)
Coordinate multi-service workflows with local transactions, compensations and a durable owner for the flow.
You see it when: Multi-service workflow (order → payment → inventory → shipping)
Choose polling, SSE or WebSocket, then separate live fan-out from durable catch-up.
You see it when: Server-initiated updates to the client
One-to-many delivery, geographic distribution, and the trade-offs that come with them.
Choose whether distribution happens on write, on read, or with a measured hybrid boundary.
You see it when: Social graph with asymmetric follow counts (power-law follower distribution)
Use a CDN as a cacheable read path, with explicit cache keys, TTLs and invalidation.
You see it when: Public, shareable content (product pages, articles, media)
Choose a regional posture for latency, disaster recovery or compliance, then make the write ownership and failover path explicit.
You see it when: Global user base with regional latency SLOs (<100 ms)
Problem-specific patterns you'll recognise on sight once you've seen them.
Build a derived search index with async ingestion, per-field analysis, ranked queries and a routine rebuild path.
You see it when: Full-text search over a corpus (millions+ of docs)
Use a real spatial index for nearby queries, then filter, rank and expire candidates so the result is both close and current.
You see it when: "Find N nearest" queries
Keep big bytes out of the app server with constrained signed uploads, async processing and private CDN delivery.
You see it when: User-uploaded media (video, images, audio)
Split recommendations into cheap candidate generation, richer ranking and feedback logging so the system can learn without blowing the request budget.
You see it when: "Recommended for you" / personalised feeds
Use token buckets, shared counters and layered identities to protect fairness without making the limiter a new outage.
You see it when: Public API with tiered plans (free, paid, enterprise)
The disciplines that turn "it works" into "it stays working".
Combine redundancy, fast failover, graceful degradation and drills so a single failure does not become a full outage.
You see it when: Availability target >= 99.95% (4 hours downtime/year or less)
Use a consensus-backed lease with fencing when exactly one replica may act; use idempotency when duplicates are tolerable.
You see it when: Distributed locks