System Design: Modules
The program treats system design as a repeatable method: pin down requirements and quality attributes, estimate scale, shape the API and data model, and justify choices through trade-offs. The method is applied to 6–8 classic case studies, each ending with a written trade-off analysis.
01
Requirements and quality attributes
Before designing, we pin down what we are solving and what we are not.
- Functional and non-functional requirements
- Availability, latency, durability and consistency attributes
- Writing constraints and assumptions down explicitly
- The notion of SLIs and SLOs
- Limiting scope
Lab: For an ambiguous task, write a list of requirements and assumptions and define the non-goals.
02
Estimation
What matters is not an exact number but an order of magnitude that affects a decision.
- Requests per second and the peak factor
- Storage and bandwidth arithmetic
- Read/write ratio
- How an estimate changes a decision
- Stating assumptions openly
Lab: Prepare a traffic and storage estimate for a chosen system and write down which decision the result affects.
03
API and data design
Starting from access patterns and shaping the API and data model around them.
- Resource and operation design
- Pagination, idempotency and rate limits
- Normalisation and denormalisation
- Matching indexes to access patterns
- Schema evolution
Lab: Produce an API contract and table schema for a given system and explain how the key queries execute.
04
Caching and queues
Weighing the value and the risk of two main tools for reducing latency and smoothing load.
- Cache-aside, write-through, write-behind
- Invalidation and stale data
- Cache stampede and protection
- Decoupling load with queues, and backpressure
- Dead letters and retries
Lab: Add a cache to a read-heavy service and simulate stale-data and stampede scenarios.
05
Storage choice and scaling
Choosing storage that fits the workload and comparing options for scaling reads and writes.
- Relational, key-value, document, search and object storage
- Read replicas and replication lag
- Shard keys and the difficulty of re-sharding
- The hot key problem
- The practical meaning of CAP and PACELC
Lab: Write a short decision document comparing two storage options for the same workload.
06
Consistency and failure modes
Thinking in advance about where and how the system will break.
- Strong, eventual and causal consistency
- Hunting single points of failure
- Timeouts, retries and idempotency
- Partial failure and degradation strategy
- Disaster recovery concepts: RPO and RTO
Lab: Prepare a failure-mode table for a designed system with a response and an impact estimate for each mode.
07
Case studies I: URL shortener, rate limiter, notifications
Applying the method to three classic problems with a relatively narrow scope.
- URL shortener: ID generation, redirect load, analytics
- Rate limiter: token bucket, sliding window, distributed counters
- Notification system: channels, priorities, retries
- Estimation and trade-off analysis for each
Lab: Pick two of the three problems and produce a full written design document with a trade-off analysis.
08
Case studies II: payments ledger, feed, search
Analysing three problems that are harder in terms of consistency, scale and retrieval.
- Payments ledger: double-entry, idempotency, audit trail
- Feed: fan-out on write versus read, hot users
- Search: inverted index, indexing delay, relevance
- Consistency and failure analysis for each
Lab: Pick one of the three problems, write a design document and rework it after peer review.