System design rounds are the most unpredictable part of senior-level interviews — and the most heavily weighted. This page covers every system design interview resource on TheCodeForge, from fundamentals to real-world design problems.
System design rounds are graded on how you think, not on whether you produce a particular architecture. There is no answer key. What the interviewer is assessing is whether you can take an ambiguous one-line prompt, turn it into requirements, make reasonable choices, and — most importantly — name the trade-offs you are accepting.
The most common failure is not a wrong component. It is starting at the components: naming a database and a queue in the first two minutes, before establishing what the system does or how large it is. A structure fixes this, and the structure itself is part of the signal.
| Phase | Time | What to produce |
|---|---|---|
| Requirements | 5 min | Three or four functional requirements, and an explicit list of what you are excluding. Ask, do not assume |
| Scale and constraints | 5 min | Users, requests per second, read:write ratio, data size per item and total, latency and availability targets |
| High-level design | 10 min | Boxes and arrows end to end: client, API, storage, async path. The whole system, shallow |
| Deep dive | 15 min | The one or two components the interviewer asks about. Data model, partitioning, algorithms |
| Bottlenecks and trade-offs | 10 min | What breaks first under load, what you would monitor, what you gave up and why |
That last phase is where senior candidates separate themselves, and it is the one most often skipped because time ran out. Budget for it deliberately — if you are at the 35-minute mark still in the deep dive, stop and move on.
Back-of-envelope numbers are not an arithmetic test. They exist so you and the interviewer agree on which architecture is under discussion, because 500 requests per second and 500,000 are different systems.
Round to powers of ten and say the assumptions. A million daily active users at ten requests each is 10⁷ requests a day, a bit over 100 per second average, maybe 500 at peak — comfortably one well-provisioned service with a cache. Ten million photos a day at 500 KB is about 5 TB daily, which immediately rules out keeping media in the primary database and makes object storage plus a CDN the obvious choice.
| Decision | Choose A when | Choose B when |
|---|---|---|
| SQL vs NoSQL | Relationships, transactions, ad-hoc queries, schema you want enforced | Known access patterns, extreme scale on one dimension, flexible or sparse documents |
| Strong vs eventual consistency | Money, inventory, anything where a stale read is a business error | Feeds, counts, timelines — where availability and latency matter more than being seconds fresh |
| Sync vs async processing | The caller genuinely needs the result to continue | Work is slow, retryable, or spiky — accept, queue, return an id |
| Cache-aside vs write-through | Reads dominate and some staleness is fine | Writes must be immediately visible and you accept write latency |
| Monolith vs microservices | One team, unclear boundaries, early product | Independent deploy cadence and scaling per component, with the operational maturity to run them |
Interviewers frequently push back on whichever you chose. That is usually not disagreement — it is a test of whether you understood the trade or memorised a preference. Defend it on the requirements you established, and be willing to change given a new constraint.
Load balancer, CDN, API gateway, application tier, cache, primary database with read replicas, object store, message queue, search index, and a background worker pool. Ten boxes cover the large majority of design questions.
What matters is being able to say why each one is present and what happens when it fails. A cache is not free: it introduces staleness, an invalidation problem, and a thundering-herd risk on expiry. A queue is not free: it makes the system eventually consistent and adds a dead-letter path someone has to own. Naming the cost alongside the component is the whole skill.
74 interview topics across coding patterns, HR questions, aptitude and more.
View All Interview Topics →