System design basics

Putting the building blocks together

You now know the parts: load balancers, stateless servers, databases, indexes, caches, queues, workers, CDNs, object storage. System design is choosing and connecting them to meet a product's requirements — and being able to explain the trade-offs. It's also a standard part of senior developer interviews.

A repeatable approach

1. Clarify requirements.
   • Functional: what must it do? ("shorten a URL", "redirect", "see stats")
   • Non-functional: how many users? reads vs writes? latency targets? consistency needs? availability?
2. Estimate the load (back-of-the-envelope).
3. Define the API — the main endpoints.
4. Design the data model — entities, keys, which database.
5. Draw the high-level architecture — the boxes and arrows.
6. Deep-dive the bottlenecks — hot paths, scaling, failure modes.
7. Discuss trade-offs — what you chose, what you gave up, what you'd do at 10× scale.

Back-of-the-envelope numbers

Fact	Value
Seconds per day	~86,400 (≈ 10⁵)
1 million requests/day	≈ 12 per second average
Peak vs average	often 2–5×
Memory read	~100 ns
Redis call in the same datacenter	~0.5–1 ms
Database query with index	~1–10 ms
Cross-continent round trip	~150 ms

Example: 100M redirects/day ≈ 1,200/s average, perhaps 5,000/s at peak. Each mapping is ~500 bytes → 1M new links/day ≈ 500 MB/day ≈ 180 GB/year. Easy for one database; the challenge is read traffic, so caching matters most.

Worked example: a URL shortener

• API: POST /links { url } → { code: "aZ3kQ9" }; GET /{code} → 301/302 redirect.
• Data: links(code PK, url, created_at, owner_id). Codes: random base62 strings (6–7 characters give billions of combinations), with a uniqueness check.
• Architecture: clients → load balancer → stateless API servers → cache (hot codes) → database. Redirect lookups are mostly cache hits.
• Trade-offs: 301 (permanent, browsers cache it — fewer requests but no analytics) vs 302 (every click reaches you). Analytics events go to a queue so redirects stay fast.

Your turn

Build architectures for three products on the canvas. Each comes with requirements and live checks; when you're done, compare with the example solution and think about what you would change at 10× the load.

Turn long URLs into short links (like bit.ly). 100 million redirects a day, but only 1 million new links. Reads vastly outnumber writes, and redirects must be fast.

📱 Client🌍 CDN⚖️ Load balancer⚙️ API server⚡ Cache🗄️ Database📚 Read replica📨 Queue🛠️ Worker🪣 Object storage

🔗 Connect selected🗑 Delete selectedClearShow an example solution

Add components with the buttons above. Click a component to select it, then “Connect selected” and click another.

Requirements check: 0/4

• ○ Clients reach the system through a load balancerOne public entry point that can route around failures.
• ○ At least 2 API servers behind the load balancerNo single point of failure, and room to scale out.
• ○ API servers store links in a databaseThe mapping short code → URL must survive restarts.
• ○ A cache sits next to the API for hot linksPopular links get millions of hits; serve them from memory.

Things to consider for each scenario

• URL shortener — Which requests dominate? What's cached? What happens if the cache is empty after a restart?
• Chat app — Users connected to different servers must exchange messages: how? (pub/sub backplane) How do offline users get messages? How are messages ordered?
• Photo news feed — Where do images live, and how do they reach users quickly? What happens when someone with 10 million followers posts? (Fan-out on write for most users; fan-out on read for celebrities.)

Key takeaways

• Start with requirements and rough numbers; let them drive the design.
• Define the API and data model before drawing boxes.
• Combine the building blocks: load balancer + stateless servers, caches for hot reads, queues for slow or bursty work, CDN and object storage for media.
• Always discuss bottlenecks, failure modes and trade-offs.