System Design Templates | Resources by Shumbul Arifa

The 6-step framework (use it every time)

Clarify requirements. What must it do (features) and how well (scale, latency)? Ask before you build. Never assume.
Estimate scale. Rough numbers: users, requests per second, storage. Order of magnitude is enough.
Define the API. A few core endpoints. This forces clarity on what the system actually does.
Sketch the high-level design. Client, load balancer, servers, database, cache. Draw the boxes and arrows.
Go deep on 1-2 pieces. Pick the interesting part (the feed, the matching, the storage) and detail it.
Discuss trade-offs and bottlenecks. What breaks first at scale? How would you fix it? This is where you shine.

See a request flow through a system

Requests flow left to right. Watch where they pile up, that saturated database is your bottleneck, exactly the kind of thing you call out in step 6.

The fix here: add read replicas or cache more aggressively so the database stops being the wall everything hits. That is the trade-off conversation interviewers love.

The building blocks (your Lego set)

Almost every design is assembled from these. Know what each one is for and the trade-off it brings.

Block	What it's for	The trade-off
Load balancer	Spread traffic across many servers	Adds a hop; needs health checks
Cache (Redis)	Serve hot data fast, cut DB load	Can go stale; needs invalidation
SQL database	Structured data, transactions, joins	Harder to scale horizontally
NoSQL database	Huge scale, flexible schema	Weaker joins and consistency
Message queue (Kafka)	Decouple work, handle spikes, async jobs	Adds complexity and eventual consistency
CDN	Serve images / static files near the user	Costs money; cache invalidation
Replication & sharding	Scale reads (replicas) and writes (shards)	Operational complexity, rebalancing

A worked example: design a URL shortener

1. Requirements: Take a long URL, return a short one. Redirect short to long. Reads far outnumber writes.

2. Scale: Say 100M new links/month, 10:1 read-to-write. That's heavy on reads, so caching matters.

3. API: POST /shorten {url} returns a short code; GET /{code} redirects.

4. Design: Client → load balancer → app servers → database of (code → url). Put a cache in front for hot links.

5. Deep dive: Generate the short code with a counter in base62, or hash the URL. Base62 of a counter avoids collisions cleanly.

6. Trade-offs: Cache reduces DB reads but can serve a deleted link briefly. A NoSQL store scales the key-value lookup well.

Keep learning (free)

System Design Primer - the classic free repo, start here.
ByteByteGo (YouTube) - short, visual explanations of real systems.
Karan's System Design guide - a clean, readable walkthrough of the concepts.

🌱 First time seeing system design? Relax

Nobody expects a fresher to design Netflix on day one. What interviewers actually want is to see you ask good questions, make trade-offs out loud, and stay organized. This page gives you a repeatable structure so you never freeze. Want to practice? Tap ✦ Ask AI and ask it to quiz you on a design.