Part 1 of 8 · week 1 of the learning path
Every large design is the same few building blocks combined to meet numbers, so learn the blocks and learn to estimate before drawing any boxes.
Learning objectives
- Turn a product request into functional and non-functional requirements.
- Do back-of-envelope estimates for traffic, storage and bandwidth.
- Explain what each core building block does and when to use it.
Requirements first
- Functional: what the system does (send a message, upload a video, charge a card).
- Non-functional: how well it does it: scale, latency, availability, durability, consistency, security and cost.
- Ask about scope and priorities before designing; a design for 1,000 users and one for 100 million are different systems.
Estimation cheat sheet
| Fact | Rule of thumb |
|---|---|
| Seconds in a day | About 86,400, so requests per day divided by 86,400 gives average QPS |
| Peak versus average | Plan for 2 to 3 times average, more for spiky products |
| Memory read | About 100 nanoseconds |
| SSD random read | About 100 microseconds |
| Round trip inside one datacenter | About 0.5 milliseconds |
| Round trip across continents | About 150 milliseconds |
| Storage | Records per day times record size times retention |
Worked example: 10 million daily users each make 20 reads and 2 writes a day. Reads are 200 million a day, about 2,300 per second on average and about 7,000 at a 3x peak. Writes are 20 million a day, about 230 per second and about 700 at peak. At 1 KB per write, that is 20 GB a day, or about 7.3 TB a year before replication.
Building blocks
| Block | Job | Key choices |
|---|---|---|
| Load balancer | Spreads requests across instances | Layer 4 or layer 7, health checks, algorithm |
| Cache | Serves hot data from memory | Cache-aside versus write-through, eviction, expiry, stampede protection |
| CDN | Serves static and cacheable content near users | What to cache, expiry, invalidation |
| Relational database | Structured data with transactions | Indexes, replicas, sharding |
| NoSQL store | Scale and flexible models | Key-value, document, wide-column, graph |
| Queue or log | Decouples producers and consumers, absorbs spikes | Ordering, retention, delivery guarantees |
| Object storage | Cheap durable storage for large files | Lifecycle, access control |
| Search index | Full text and filtered queries | Refresh lag, relevance |
| Rate limiter | Protects services from abuse and overload | Token bucket, per-user or per-key limits |
Scaling basics: make services stateless so any instance can serve any request; scale out behind a load balancer; cache reads; replicate data for reads and safety; shard data when one node cannot hold or write it all. When the network splits, a distributed store must choose consistency or availability, so decide per feature which matters more.
Design exercise: a URL shortener gets 100 million new links a month with ten reads per write. Estimate write and read QPS, storage over five years and cache size for the hottest 20% of links, then list the blocks you would use.
Quiz 1 (5 questions, pass mark 4)
- About what is the average QPS for 86.4 million requests a day?
- A) 100
- B) 1,000
- C) 10,000
- D) 86,400
- Why is a stateless service easy to scale?
- A) It uses sticky sessions
- B) It keeps sessions in local memory
- C) Any instance can serve any request, so you add instances behind a load balancer
- D) It needs a single large server
- What is cache-aside?
- A) The cache is the only store
- B) Reads bypass the cache
- C) The database pushes every write into the cache
- D) The app checks the cache first and, on a miss, reads the database and fills the cache
- What does a CDN mainly do?
- A) Serves static and cacheable content from locations near users, cutting latency and origin load
- B) Stores financial transactions
- C) Runs SQL queries
- D) Encrypts the database
- How should you size for traffic peaks?
- A) Use the average only
- B) Ignore peaks
- C) Plan for a multiple of average, commonly 2 to 3 times or more, plus headroom
- D) Assume every second is a peak
Quiz 1 answers
Sources and further reading
- Latency numbers every programmer should know, the Jeff Dean and Peter Norvig figures behind the estimation table; the numbers are rough and dated, so use them for orders of magnitude.
- System Design Primer, an open study guide covering the building blocks in this module.
- Designing Data-Intensive Applications by Martin Kleppmann, for caching, replication and consistency in depth.
Part 1 of 8 in the System Design Learning Path series. Next: part 2.
Top comments (0)