system-design

Build-It Projects

The deepest way to learn system design is to build the systems — even tiny versions. Reading about a rate limiter is one thing; implementing a token bucket in Redis and watching it reject requests is another. This chapter is a graded ladder of buildable projects that turn abstract concepts into things you can point to, run, and put on a resume — invaluable for fresh grads with no industry experience.

Prerequisites: Case Studies, a programming language you’re comfortable in Time: each project is a weekend to a few weeks

Why build, not just read

🚨 Building forces you to confront the details reading lets you skip. When you implement a cache, you hit invalidation, eviction, and the thundering herd for real. When you build a URL shortener, you face ID generation, collisions, and the read/write split concretely. Concepts you “understood” reveal their sharp edges only when your code has to actually work.

For fresh grads with no job experience, build-it projects are doubly valuable:

They give you concrete things to talk about in interviews (“I built X, here’s the trade-off I hit”).
They’re portfolio pieces (GitHub repos, a blog post) that make you stand out with no work history.
They build genuine intuition that pure study can’t.

🚨 You don’t need to build at production scale — a working small version that demonstrates the core concept is the goal. Build the idea, not the whole company.

How to approach a build project

Start with the core concept, not the polish. For a rate limiter, that’s the algorithm + shared counter — not a fancy dashboard.
Make it actually work end to end, even if tiny.
Then push one dimension: make it distributed, add persistence, load-test it, handle a failure.
Write up what you learned — the trade-off you hit, the thing that surprised you. This is the part that impresses interviewers and cements the learning.
Load-test it (even lightly) to see the bottleneck you read about.

The project ladder

🟢 Beginner — one concept each (a weekend)

Project	Core concept	Push it further
URL shortener	ID generation, read/write split, key-value storage	Add a cache; measure hit rate; base-62 encoding (case study)
Rate limiter	Token bucket / sliding window, shared counter	Make it distributed with Redis + Lua atomicity (case study)
Key-value store	Hash map + persistence + TTL	Add an append-only log; crash recovery
In-memory cache with LRU	Eviction policy, capacity bounds	Add TTL, then make it a small server
Pastebin	Metadata/blob split, expiration	Store blobs on disk/S3; add a CDN in front

🟡 Intermediate — a few concepts together (1–2 weeks)

Project	Core concepts	Push it further
Chat app	WebSockets, real-time push, message persistence	Presence, offline delivery, multiple rooms (case study)
A small message queue	Append-only log, offsets, consumer position	Partitions, at-least-once + idempotency (case study)
Web crawler	Frontier queue, dedup, politeness	Bloom filter for seen-URLs; concurrency (case study)
A job scheduler	Durable jobs, due-time index, workers	Leader election; lease-based retry (case study)
Leaderboard	Sorted set, rank queries	Back it with Redis ZSET; time-scoped boards (case study)
Notification service	Queue + workers, retries, providers	Idempotency, circuit breaker on a fake flaky provider (case study)

🔴 Advanced — a real distributed system (a few weeks+)

Project	Core concepts	Push it further
Distributed KV store	Consistent hashing, replication, quorums	Hinted handoff, read-repair (case study)
A mini social feed	Fan-out, timeline cache, hydration	Hybrid fan-out for “celebrities” (case study)
A metrics/monitoring toy	Time-series ingestion, downsampling, query	Compression; cardinality limits (case study)
Raft implementation	Consensus, leader election, log replication	Follow the Raft paper; visualize it (Consensus)
A URL shortener at “scale”	The full 1→1B journey on real infra	Load balancer, cache, sharded DB, load test (1→1B)

Load-testing: see the bottleneck

🚨 Whatever you build, throw load at it (tools: wrk, k6, hey, or a simple script). This is where theory becomes visceral:

Watch latency climb as QPS rises → find your system’s ceiling.
Add a cache → watch the DB load drop and latency fall.
Remove the cache and expire a hot key → see a thundering herd.
Add a second server + load balancer → watch throughput scale (or not).

You’ll internalize finding bottlenecks and the 1→1B journey far better than by reading them.

Turn projects into interview gold

A built project gives you a story — use it:

“I built a distributed rate limiter. The naive per-server version let clients exceed the limit, so I moved the counter to Redis and used a Lua script for atomicity — that taught me why the read-modify-write race matters.”
This shows initiative, hands-on skill, and — crucially — that you’ve hit real trade-offs, which is exactly what design interviews probe. 🚨 For a fresh grad, one deep build project you can discuss fluently beats a dozen you skimmed.

Write a short blog post or README per project explaining the design and what you learned. It doubles as portfolio and as design-interview rehearsal.

🛠️ Try it

1. Ship a beginner project this month. Pick one 🟢 project, build the core in a weekend, then push one dimension (distribute it, persist it, or load-test it) the next weekend. Put it on GitHub with a README explaining the design.

2. Load-test something you built. Point k6/wrk at it, ramp the QPS, and graph latency. Find the ceiling, add a cache or a second instance, and watch it move. Screenshot the before/after.

3. Write the trade-off up. In one page: what you built, the key decision you faced, the trade-off, and what surprised you. This becomes both a portfolio piece and a rehearsed interview story.