System Design · Lesson 1

System Design Basics

System design is the discipline of turning product requirements into an architecture that can handle expected traffic, data, failures and future growth.

Rate limiting Circuit breakers Caching Design problems

1. Start with requirements

Separate functional requirements from non-functional requirements. Functional requirements describe what the product must do. Non-functional requirements describe qualities such as latency, availability, durability, consistency, security and cost.

2. Estimate the workload

Estimate daily active users, peak requests per second, read/write ratio, payload size and storage growth. The goal is not perfect math; it is to understand which component will become the first bottleneck.

Worked example

Design a URL shortener

Assume 10 million new short URLs per month, a 100:1 read/write ratio, and a requirement that redirects should usually complete in under 100 ms.

Write path

API → ID generator → relational or key-value store. A unique short code is generated and mapped to the long URL.

Read path

Browser → load balancer → stateless redirect service → cache → database fallback.

GET /aB91x ↓ Load balancer ↓ Redirect service ↓ Redis cache ── hit → 302 redirect └─ miss → DB → cache → 302

Back-of-the-envelope estimate

If 10 million links are created monthly, that is roughly 4 writes/second on average. With a 100:1 read/write ratio, average reads are only a few hundred per second; peak traffic may be much higher, but a single well-tuned database plus cache can handle the first version.

Trade-off: do not start with sharding just because URL shorteners are “system design” problems. Add distributed complexity when the expected workload justifies it.

3. Define interfaces and data

Sketch the main API operations and the data entities they touch. Choose storage based on access patterns rather than fashion.

4. Draw the simplest architecture that meets the requirements

A typical web system may include clients, a load balancer, stateless application servers, a primary database, caches, object storage and background workers. Introduce extra components only when a requirement justifies them.

5. Ask how it fails

What happens when traffic doubles, the database slows down, a downstream API fails or one server disappears? Timeouts, retries, circuit breakers, replication, queues and idempotency should be tied to specific failure modes.

Interview rule: communicate assumptions and trade-offs. The reasoning matters more than drawing the maximum number of boxes.