Requirements
Start with user behavior and business constraints. Functional requirements describe what the system does; non-functional requirements define how well it must do it.
A PRACTICAL FIELD GUIDE
Design systems
that survive
reality.
System design is the practice of turning product requirements into software that remains useful as traffic grows, dependencies fail, and teams evolve.
REQUIREMENTS→TRADE-OFFS→ARCHITECTURE→OPERATIONS
REFERENCE SYSTEMREQUEST → RESPONSE + EVENTS
WEBMOBILEAPI
↓
EDGE / LOAD BALANCER
↓
SERVICE ASERVICE BSERVICE C
↙↓↘
CACHEDATABASEQUEUE
THE CORE IDEA
There is no perfect architecture.
There is an architecture whose trade-offs match the problem.
01 / START WITH THE PROBLEM
Architecture begins
before the diagram.
A useful design explains why each component exists. These four questions establish the evidence for every later decision.
Scale
Estimate traffic, storage, bandwidth, and growth. Rough numbers expose the shape of the problem before a single technology is chosen.
Data
Model the entities, access patterns, ownership, retention, and consistency needs. The best database depends on how the data will be used.
Failure
Assume networks partition, machines restart, dependencies slow down, and messages arrive twice. Reliability comes from designing those states explicitly.
02 / THE BUILDING BLOCKS
A system is a chain
of responsibilities.
Components are not goals. Add one when it solves a measured constraint or isolates a meaningful failure mode.
Client
Initiates work and renders results. Web, mobile, devices, or another service.
Edge + CDN
Terminates connections and serves content near users to reduce latency and origin load.
Load balancer
Distributes requests across healthy instances and removes failed ones from rotation.
Service
Applies domain rules. Stateless services are easier to replicate horizontally.
Cache
Trades freshness and complexity for lower latency and database pressure.
Database
Persists source-of-truth state with a consistency model and access strategy.
Queue / stream
Decouples producers from consumers and absorbs bursts of asynchronous work.
Observability
Makes behavior visible through metrics, logs, traces, alerts, and business signals.
03 / SCALE WITH INTENT
Four patterns that
change the shape.
Scaling is not adding everything at once. It is locating the current constraint and applying the smallest useful pattern.
Make more copies.
DB→RRR
Read replicas increase read capacity and resilience. They introduce replication lag, so not every read is guaranteed to be current.
Split responsibility.
A–FG–MN–Z
Partition data by a stable key to distribute storage and writes. Poor keys create hot partitions and painful rebalancing.
Reuse expensive answers.
APP→CACHE↘DB
Cache frequent reads near consumers. Define eviction, invalidation, fallback, and acceptable staleness before relying on it.
Separate time.
API→QUEUE→WORKER
Queues absorb bursts and isolate failures. Plan for retries, duplicates, poison messages, backpressure, and monitoring.
04 / SYSTEMS IN CONTEXT
Same building blocks.
Different priorities.
Compare how product behavior changes the architecture. Each example optimizes a different critical path.
CASE 01
URL shortener
Read-heavy · global · small objects
DESIGN QUESTION
How do we redirect billions of short links with very low latency?
Client→Edge cache→Redirect API→Key-value store
- Generate compact, unique IDs without coordinating every request through one machine.
- Cache popular mappings at the edge because reads greatly outnumber writes.
- Use an asynchronous analytics pipeline so click tracking never delays the redirect.
CASE 02
Real-time chat
Connection-heavy · real-time · ordered
DESIGN QUESTION
How do we preserve conversation order while users move between devices?
WebSocket→Gateway→Chat service→Log + fan-out
- Keep long-lived connections in gateways and route a conversation to an owning partition.
- Assign server-side sequence numbers to order messages within each conversation.
- Persist before acknowledging, then fan out to online users and notify offline users.
CASE 03
Video platform
Storage-heavy · bandwidth-heavy · asynchronous
DESIGN QUESTION
How do we accept large uploads and stream efficiently to a global audience?
Direct upload→Object storage→Transcoding queue→CDN
- Upload directly to object storage with a signed URL instead of passing video through the API.
- Transcode asynchronously into multiple resolutions and formats with retryable workers.
- Serve immutable segments through a CDN and keep metadata in a separate database.
CASE 04
E-commerce checkout
Write-critical · multi-service · correctness-first
DESIGN QUESTION
How do we coordinate inventory, payment, and orders without a distributed transaction?
Checkout API→Order state→Event bus→Payment + stock
- Create an order in a pending state and advance it through an explicit workflow.
- Use idempotency keys for payment and deduplicate events at every consumer.
- Compensate when a later step fails: release stock or issue a refund.
05 / MAKE TRADE-OFFS EXPLICIT
Every guarantee
has a cost.
A mature design states what it protects, what it relaxes, and how users experience that choice.
| Priority | What it means | Often critical for | Typical cost |
|---|---|---|---|
| Consistency | Every reader sees the latest accepted write. | Payments, inventory, permissions. | More coordination and potentially higher latency. |
| Availability | The system responds even when part of it is impaired. | Feeds, catalogs, cached content. | Responses may be stale or incomplete. |
| Low latency | The user receives a response quickly. | Search suggestions, gaming, chat. | Caching, replication, and operational complexity. |
| Durability | Accepted data survives failures. | Orders, files, audit records. | Extra replicas, acknowledgements, and cost. |
ABOUT CAP
During a network partition, a distributed system must choose how strongly to preserve consistency or availability for a given operation. CAP is not a database ranking; it is a framework for reasoning about behavior under partition.
06 / A REPEATABLE DESIGN METHOD
Move from ambiguity
to an operable system.
The order prevents premature technology choices and keeps the design connected to user outcomes.
- 01
Clarify
Users, core actions, boundaries, constraints, and what is explicitly out of scope.
- 02
Estimate
Peak requests, data size, read/write ratio, bandwidth, and expected growth.
- 03
Design the API
Define the contract and make retries, pagination, errors, and versioning explicit.
- 04
Model the data
Choose entities, keys, indexes, partitions, retention, and consistency per workflow.
- 05
Draw the flow
Place the minimum components needed for the critical read and write paths.
- 06
Stress the design
Find bottlenecks, hot keys, dependency failures, overload behavior, and recovery paths.
- 07
Operate it
Add service-level objectives, signals, alerts, capacity plans, and safe deployment paths.
08 / FIELD NOTES
Architecture decisions
from runtime to storage.
Practical essays that connect execution and data models with the behavior, limits, and failure modes of production systems.
POSTGRES · STORAGE & MVCC · 16 MIN · ES/EN
Postgres never
overwrites a row.
Pages of 8 KB, line pointers, ctid, what a B-tree index really stores, xmin/xmax visibility, HOT updates, dead tuples, bloat, and why one long transaction holds vacuum back across the whole instance.
DATABASES · DATA MODELING · 18 MIN · ES/EN
Choose a database from
the questions, not the logo.
A practical guide to access patterns, relational and NoSQL models, normalization, indexes, sharding, CAP, and polyglot persistence with one source of truth.
PYTHON · CONCURRENCIA · 16 MIN
Concurrencia vs. paralelismo:
cómo elegir y diseñar el sistema.
Una guía para distinguir espera de cómputo, elegir entre asyncio, threads y procesos, y convertir esa decisión en un sistema con límites, backpressure y fallos controlados.
Leer el artículo ↗ALGORITHMS · DATA STRUCTURES · 14 MIN · EN
Data structures & Big O:
choose by workload, not habit.
A practical comparison of arrays, hash tables, trees, heaps, queues, and tries— including the operations each one makes cheap and the real-world costs Big O leaves out.
Read the article ↗09 / READING THE CLASSICS
A chapter-by-chapter study of
Designing Data-Intensive Applications.
Kleppmann's book is the reference most system design conversations quietly borrow from. These are my own notes, written to be studied: one page per chapter, with the arguments redrawn as diagrams.
CHAPTER 01 Available
Reliable, Scalable, and Maintainable Applications
The three concerns that justify every later decision, and why "is it scalable?" is the wrong question.
- Reliability — faults, failures, and the three ways systems break
- Scalability — load parameters, fan-out, and why the tail is the story
- Maintainability — operability, simplicity, evolvability
Designing Data-Intensive Applications Martin Kleppmann · 1st edition, 2017
- 01 Reliable, Scalable, and Maintainable Applications I · Foundations
- 02 Data Models and Query Languages I · Foundations
- 03 Storage and Retrieval I · Foundations
- 04 Encoding and Evolution I · Foundations
- 05 Replication II · Distributed Data
- 06 Partitioning II · Distributed Data
- 07 Transactions II · Distributed Data
- 08 The Trouble with Distributed Systems II · Distributed Data
- 09 Consistency and Consensus II · Distributed Data
- 10 Batch Processing III · Derived Data
- 11 Stream Processing III · Derived Data
- 12 The Future of Data Systems III · Derived Data
Original study notes and diagrams. The book itself is by Martin Kleppmann (O'Reilly Media, 1st edition, 2017) — dataintensive.net.
THE DEFINITION OF DONE
A good design is
explainable.
You can trace every component to a requirement, describe its failure behavior, measure its health, and name the trade-off you accepted.
Review from the top ↑