System design (backend)
Part of the Backend Developer Roadmap
In short
System design rounds aren't about a perfect diagram. They test whether you ask good questions, estimate sensibly, start simple and explain trade-offs out loud.
Higher-level interview questions about architecting a backend system — API design, data modeling, scaling strategy, trade-offs — common from mid-level interviews onward.
Think of it like this
Planning a big Indian wedding
Before booking anything you ask: how many guests, veg or non-veg, which city, what budget? Then you size the tent, the caterer and parking. Booking a palace for 50 guests is as wrong as a tiny hall for 2,000.
Watch it happen
A 45-minute design round
1/6Ask what must work (features) and how well (scale, latency, availability). Write the answers down.
The big ideas
What you need to know
Clarify before drawing
Five minutes of questions saves you from designing the wrong system. Interviewers expect it.
Estimate out loud
86,400 seconds in a day is your friend. Rough maths shows whether one database is enough.
Start simple, then scale
One server and one database first. Add cache, replicas, queues or sharding only when a number demands it.
Name the trade-offs
"Caching makes reads fast but data can be stale for 60 seconds. Is that okay here?"
See it in code
Walk through the code
1// Back-of-envelope for a URL shortener, said out loud in the interview2const newLinksPerDay = 1_000_000; // assumption: agree it with the interviewer3const readsPerWrite = 100; // links are clicked far more than created4 5const writesPerSec = newLinksPerDay / 86_400; // ≈ 12 writes/sec6const readsPerSec = writesPerSec * readsPerWrite; // ≈ 1,160 reads/sec7const peakReads = readsPerSec * 3; // plan for about 3x at peak8 9const bytesPerLink = 500; // URL + code + metadata10const storagePerYearGB = (newLinksPerDay * 365 * bytesPerLink) / 1e9; // ≈ 183 GB1/3State your assumptions clearly. The interviewer may change them.
These numbers say a single Postgres can store a year of links, and a cache will absorb most reads. That shapes the whole design.
Save yourself the pain
Common mistakes
Oops
Jumping straight to Kafka, Kubernetes and ten microservices.
Do this instead
Start with the simplest design that meets the numbers, then add parts only when you can say why.
Oops
Talking silently to yourself while drawing.
Do this instead
Think out loud. The interviewer grades your reasoning, not just the final diagram.
Your mission
Run a mock design round
Quick check
The interviewer says "Design a chat app". What's the best first move?
Go deeper
- 1Practice a mock system design question, e.g. 'design a URL shortener' or 'design a rate limiter'.
- 2Structure your answer: requirements, high-level design, data model, scaling, trade-offs.
- 3Study how a real product you use is likely architected, as a reference point.
More technical at this stop
Node.js, Express, Databases, APIs
Database design & normalization
HTTP & REST fundamentals
Caching strategies
Concurrency & the event loop
Security (OWASP Top 10)
Debugging distributed systems
Stuck on this topic? Ask an Insider
Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.
