Concept Library

Keep replicas and reads aligned enough for the product guarantees you promised.

Break a vague problem into functional requirements, non-functional requirements, and explicit non-goals.

Define measurable availability, latency, and throughput targets before designing.

Surface the hard constraints (regulatory, latency, budget) that narrow the design space.

Before drawing boxes, ask five questions. The answers change every downstream decision.

FRs describe WHAT the system does. NFRs describe HOW WELL. Miss either and you're designing in the dark.

Explicitly saying what you won't build is as valuable as saying what you will.

Estimate QPS, storage, and bandwidth from DAU using simple arithmetic.

Size infrastructure for current load plus growth with headroom for spikes.

Map read/write ratios and access patterns to identify which operations dominate.

Compute the network bandwidth your system actually needs — most designs miss this until it's too late.

Real-time systems are bounded by concurrent connection count — count them before you count QPS.

Understand what p50/p95/p99 mean and why averages lie about latency.

Extrapolate how much storage you'll need in 6 and 12 months — not just day one.

Design clean API endpoints with proper resource naming, methods, and response shapes.

Choose between offset, cursor, and keyset pagination based on data characteristics.

Ensure repeated requests produce the same result — critical for payment and write-heavy APIs.

Pick a versioning strategy before your first breaking change forces one — three options, one easy answer.

Design the data model before sketching endpoints — storage layout constrains every API choice downstream.

Consistent error responses prevent clients from writing error handling as an afterthought.

Long-polling, Server-Sent Events, and WebSockets — pick based on direction, frequency, and client capability.

Break a system into services/components with clear responsibilities and interfaces.

Trace how data moves through the system for each key operation (read path, write path).

Draw boundaries so each service owns its data and communicates through APIs, not shared DBs.

A sketch becomes a diagram when every box and arrow carries meaning. Four conventions do most of the work.

RPC says "do this and tell me the result." Events say "this happened, fan out." Architectures get complex when you conflate them.

Synchronous calls block the caller; async calls don't. Most coupling bugs come from mixing these up.

Find the specific key, partition, or path that receives disproportionate traffic.

Prevent all clients from hitting the origin simultaneously when a cache entry expires.

Pooled connections are a finite resource — one slow query can block the entire app.

Understand what p50/p95/p99 mean and why averages lie about latency.

A shared lock can make a 64-core server behave like a 1-core one — identify it before you blame hardware.

When consumers fall behind producers, queues grow unbounded — and then everything crashes at once.

One logical operation often triggers many physical ones — spot when 1 → N is breaking you.

Find the single point of failure — especially the hidden ones nobody thinks about.

Reason about p95/p99, not just averages — tail latency is what users actually feel.

Store hot data close to the request path to cut latency and reduce origin load.

Decouple producers and consumers so slow work can run asynchronously.

Spread traffic across workers so no single instance becomes the bottleneck.

Partition data across multiple database instances to distribute write load.

Choose single-leader, multi-leader, or leaderless replication based on availability and consistency needs.

When multiple nodes must agree on a single value, you need consensus. Raft is the right answer 95% of the time.

Design for the failures you expect, not the happy path you hope for. Three categories: slow, broken, wrong.

Multi-region is expensive. Know the specific reason you need it — latency, availability, or regulation — before you do.

Stateless services scale horizontally by adding instances. Stateful ones require coordination. Most "why won't this scale" problems start with accidental state.

Decouple producers and consumers so slow work can run asynchronously.

Keep replicas and reads aligned enough for the product guarantees you promised.

Explicitly state your availability vs consistency choice and justify it for the use case.

Map where your feature sits on the spectrum from low-latency/eventual to high-latency/strong.

Building in-house is cheaper at small scale, more expensive at large scale — and the crossover is different for every category.

Performance optimizations have costs. Make the tradeoff explicit — "this costs $X to save Y ms" — or you'll over-engineer.

Microservices add network, deployment, and operational complexity. Monoliths have fewer moving parts. Pick based on team coordination pain, not headcount.

For social fan-out, push-on-write is fast to read but expensive to write. Pull-on-read is the opposite. Real systems use both, chosen by follower count.

Different features in the same system can have different consistency needs. Don't pay for strong where eventual is fine.