System design · Day 1
Start here: how a web request becomes a system
Build the mental model for clients, servers, state, latency, throughput, and the request path every later lesson will extend.
System design is the practice of arranging software and infrastructure so a product can keep its promises as users, data, traffic, and failure grow.
Follow one request
When a user opens a page, a client sends a request over the network. A server validates it, runs product logic, reads or changes data, and sends a response. Even a large architecture is this path repeated, distributed, cached, queued, and observed.
Draw that smallest path first: client → application → database. Label where state lives and where the network is crossed. Every extra component in later lessons should solve a measured problem on this diagram.
Learn the four basic pressures
Latency is how long one operation takes. Throughput is how many operations complete in a period. Availability is the fraction of time the service can fulfill requests. Durability is the chance that accepted data remains intact.
These goals can conflict. Waiting for several data copies improves durability but adds latency. Serving a nearby cached copy reduces latency but may return older data. System design is the work of naming and choosing those trade-offs.
Scale by finding the pressure
Vertical scaling gives one machine more resources; horizontal scaling adds machines. Horizontal scale requires traffic distribution and moving state out of individual application instances, concepts developed on Day 3 and Day 8.
Do not begin by adding every tool you know. Day 2 teaches requirements and estimation so the size and shape of the actual problem—not an imaginary internet-scale workload—decides what comes next.
“Begin with one request, one promise, and one bottleneck. Complexity should be earned.”