LESSON 1.4
The building blocks
A tour of the parts almost every system is made from, what each one is for, and the problem that makes you reach for it.
6 min read
Nearly every system you will design is assembled from the same dozen parts. Once you know what each part is for, and which problem makes you add it, most designs become a matter of picking the right ones and wiring them together.
Here is a typical, fairly complete web system. Do not worry about every box yet; each one gets its own module later.
Clients and DNS
The client is whatever sends the request: a browser, a mobile app, another service. Before it can send anything it asks DNS to turn a name like api.example.com into an IP address. DNS is also a simple, coarse tool for spreading traffic across regions.
Load balancer
Problem it solves: one server cannot handle all the traffic, or you cannot afford downtime when it restarts.
A load balancer receives every request and forwards each one to one of many identical servers. It also stops sending traffic to servers that fail health checks. It only works if the servers are stateless: anything a server needs to remember between requests (sessions, uploads in progress) has to live somewhere shared, like a database or cache.
Application servers
The servers that run your code. They validate input, apply business rules, and read and write data. Keep them stateless and you can add or remove them freely as traffic changes. This is called horizontal scaling.
Databases
The source of truth. Relational databases (Postgres, MySQL) give you tables, joins and transactions. NoSQL stores (DynamoDB, Cassandra, MongoDB) give up some of that for easier horizontal scaling or flexible data shapes. Choosing and scaling the database is often the hardest part of a design; it gets two whole modules.
Cache
Problem it solves: the same data is read over and over, and the database is too slow or too busy to serve it every time.
A cache (usually Redis or Memcached) keeps hot data in memory. Reads that hit the cache take well under a millisecond and never touch the database. The cost is that cached data can be stale, and you have to decide when to update or evict it.
Message queue
Problem it solves: some work is slow, bursty or unreliable, and the user should not wait for it.
The server puts a message on a queue (SQS, RabbitMQ, Kafka) and returns. Workers take messages off the queue and do the work: sending email, resizing images, charging cards. If a worker fails, the message is retried. If traffic spikes, the queue grows and workers catch up later instead of everything falling over.
Object storage and CDN
Object storage (S3, GCS) holds large files: images, videos, backups. It is cheap, practically infinitely large and very durable. A CDN caches those files (and other static content) on servers close to users around the world, so a user in Mumbai downloads from Mumbai, not Virginia.
Search, streams and more
Later modules add more specialized parts: search indexes (Elasticsearch) for full-text queries, event streams (Kafka) for feeding many consumers the same events, coordination services (ZooKeeper, etcd) for leader election and locks. They all follow the same rule: add one when a requirement creates a problem it solves.
The cheat sheet
| Building block | Add it when… | Watch out for |
|---|---|---|
| Load balancer | One server is not enough, or must not be a single point of failure | Servers must be stateless |
| Cache | The same data is read far more than it changes | Staleness, invalidation, cold starts |
| Read replicas | The database is overloaded with reads | Replication lag |
| Queue + workers | Work is slow, bursty or can happen later | Duplicates, ordering, poison messages |
| Object storage | You store files or large blobs | Keep metadata in the database |
| CDN | Users far away download static content | Cache invalidation on change |
| Sharding | One database cannot hold the data or the writes | Cross-shard queries, hot keys |
Try it
Image Processing Pipeline HLD
A design that needs object storage, a queue and workers, each for a clear reason.