System Design Interview Prep: From Monolith to Microservices

The thing that trips people up about system design interviews isn't the architecture, it's that there's no single correct answer to memorize. A coding interview has a right answer you can verify against test cases. A system design interview evaluates how you think under ambiguity, which means the same design can be a strong answer from one candidate and a weak one from another, depending entirely on whether they understood why they made each choice. This guide walks through the actual process, not a diagram to copy.

What the interview is really testing

A typical round runs 45 to 60 minutes and, underneath the specific prompt (design Twitter, design a URL shortener, design a chat app), it's testing five things:

1. Whether you gather requirements before designing. Jumping straight to a diagram is the single most common way candidates lose points, because it signals you'll build the wrong thing quickly rather than the right thing carefully.
2. Whether you can produce a coherent high-level design that actually satisfies the requirements you just gathered, not a generic architecture you memorized.
3. Whether you can go deep on request, when the interviewer picks one box in your diagram and asks "how does that actually work internally?"
4. Whether you understand how the design breaks at scale, and what specifically you'd change as load grows by 10x, then 100x.
5. Whether you can justify trade-offs out loud, because every real design decision costs something, and pretending otherwise reads as inexperience, not confidence.

None of these are about having seen the exact problem before. They're about process, which is why the framework below works whether the prompt is a URL shortener or a video platform.

Start by asking, not designing

The instinct to prove competence by sketching architecture immediately is exactly backwards. A vague prompt like "design Twitter" is deliberately underspecified, the same way a vague ticket is underspecified: your job is to narrow it before you build anything.

Useful clarifying questions for almost any prompt:

• What's the expected scale? A system for 10,000 users looks nothing like one for 100 million, and guessing wrong wastes the rest of the interview.
• What's the read/write ratio? A feed-heavy product like Twitter is read-heavy by a wide margin (closer to 100:1 than 1:1), and that ratio should shape nearly every downstream decision, especially around caching.
• What has to be exact versus approximate? A "like count" can lag reality by a few seconds with nobody noticing. A bank balance cannot. Knowing which one you're building changes whether eventual consistency is acceptable.
• What's explicitly out of scope? Interviewers often want you to not design authentication or the mobile client, and asking saves you from burning 15 minutes on something nobody's grading.

Spend three to five minutes here. It feels slow when the clock is running, but a well-scoped design for the right problem beats a polished design for the wrong one every time, and interviewers notice the difference between a candidate who asked and one who assumed.

Build the simplest version first, then scale it

A pattern that reads well in interviews: state the simple, obviously-correct design before the scaled one, and narrate why it eventually breaks. This shows you understand why complexity gets added, rather than reaching for Kafka and sharding because they sound impressive.

Take a URL shortener as the running example. The simple version is almost embarrassingly small: one server, one database table mapping a short code to a long URL, and a hash function (or an auto-incrementing ID converted to base62) to generate the code. That design correctly handles a few thousand users. State it, then say what breaks it: at high write volume, a single database becomes the bottleneck for both reads and writes, and a single server becomes a single point of failure.

From there, layer in changes and justify each one against the specific pressure it relieves:

Client -> Load Balancer -> [App Server, App Server, App Server]
                                    |
                              Cache (Redis)
                                    |
                          Database (sharded by short code hash)

• A load balancer removes the single point of failure and spreads requests across multiple app servers. Trade-off: it adds a hop and a component that itself needs to be highly available, which is why production load balancers are typically managed services, not something teams build themselves.
• A cache in front of the database absorbs read traffic, and for a URL shortener the read-to-write ratio is enormous (people click links far more than they create them), so this is close to free performance. Trade-off: cached data can go briefly stale, and for this use case that's fine; for a system tracking account balances, it usually isn't.
• Database sharding splits the write load across multiple databases once a single instance can't keep up, typically by hashing the short code and routing to a shard based on the hash. Trade-off: queries that need to span shards (rare here, common in other systems) get significantly harder, and resharding later, if you picked the wrong shard key, is a genuinely painful migration.

Notice the shape of the answer: every added piece has a stated reason it exists and a stated cost. That's what interviewers are listening for, not the vocabulary word itself.

The vocabulary you actually need, and what each word costs

You don't need to have memorized twenty architecture patterns. You need to deeply understand a handful, because they cover the overwhelming majority of interview prompts:

Caching trades a small amount of staleness risk for a large amount of speed and reduced database load. The failure mode to know: cache invalidation, deciding when cached data is no longer trustworthy, is a genuinely hard problem, and saying so out loud (rather than treating caching as a free win) is a point in your favor.

Message queues (Kafka, RabbitMQ, SQS) decouple a producer from a consumer, letting the producer respond fast while work happens asynchronously. The cost is complexity: you now have to reason about message ordering, at-least-once versus exactly-once delivery, and what happens when a consumer falls behind or crashes mid-processing.

Database replication (a primary handling writes, replicas serving reads) improves read throughput and adds resilience if the primary fails. The cost is replication lag: replicas are slightly behind the primary, so a user who just wrote data might not see it if their next read hits a replica, which is a real bug class called read-your-own-write inconsistency.

Sharding splits one large dataset across multiple databases by some key (user ID, geography, hash of an entity ID). It's how you scale writes past what one machine can handle. The cost is that any query needing data from multiple shards, or any need to change the shard key later, becomes substantially harder than it would be on a single database.

CDNs push static content (images, video, JS bundles) physically closer to users, cutting latency. The cost is mostly operational: cache invalidation across edge locations and a real dollar cost per byte served.

Knowing these five well, including their costs, covers most interview prompts better than a shallow familiarity with twenty patterns you can't defend under a follow-up question.

A worked example: designing a feed like Twitter's

Requirements (after asking): 100 million active users, read-heavy at roughly 100:1, feed updates should feel close to real-time, full-text search is a stated but secondary requirement.

The core design decision is how you generate each user's feed, and there are two real approaches worth stating by name because interviewers specifically listen for this trade-off:

Fan-out on write: when a user posts, immediately push that post into the feed storage of every follower. Reads are then trivially fast, just fetch the pre-built feed. The cost shows up for accounts with millions of followers: one post triggers millions of writes, which is a real operational problem, not a theoretical one.

Fan-out on read: store posts once, and build each user's feed at request time by pulling recent posts from everyone they follow. Writes stay cheap and simple. The cost moves to read time: assembling a feed live, especially for someone following thousands of accounts, is slower and more expensive per request.

The honest answer production systems actually use is both: fan-out on write for most users, and a fallback to fan-out on read specifically for accounts with unusually large follower counts, so one celebrity post doesn't create a write storm. Saying this, and explaining why neither pure approach survives contact with real usage patterns, is a stronger answer than confidently picking one and defending it as universally correct.

What separates a strong answer from a weak one

The biggest tell interviewers describe is candidates who state a diagram accurately but can't explain what it protects against or what it costs. Practice narrating why out loud, not just what: not "add a cache" but "add a cache because our read-to-write ratio is high enough that this removes most database load cheaply, and the acceptable staleness here is seconds, not milliseconds." Practice this on the same handful of well-known problems (URL shortener, chat app, feed system, rate limiter) until the narration becomes natural, because the structure transfers almost entirely between prompts even when the surface details change.

Also practice actually drawing while you talk, even in a text-only interview tool. A rough box diagram, described as you build it, keeps you and the interviewer oriented in a way that pure narration doesn't, and it gives the interviewer a natural place to point when they ask you to go deeper on one component.

Want structured practice? Kodion's AI mock interviews run full system design rounds with follow-up questions that probe exactly the trade-offs covered here.