Home / Blog / System design interview: a senior engineer’s checklist

System design interview: a senior engineer’s checklist

PrepHike · 8 min read

The system design round is where most mid-level engineers in India stall. Not because they lack knowledge, but because they answer the wrong question, skip the structure interviewers expect, and never name a single trade-off. This checklist is the order a senior engineer actually works in.

Why the system design round filters so many people

If you have 3 to 6 years of experience, the coding round rarely decides your offer. The system design interview does. It is the round that separates a 12 LPA band from a 28 LPA band, because it tests whether you can own a service, not just close a ticket. And it is the round most engineers in India prepare for the least, usually because their day job is feature work on an existing codebase, not greenfield design.

The good news: this round rewards structure more than raw memory. An interviewer is not waiting for you to recite the internals of Kafka. They want to see whether you scope a vague problem, reason about numbers, choose components for stated reasons, and admit what your design gives up. Below is the sequence senior engineers use, with the specifics that actually move a score.

Step 1: Scope the problem before you draw anything

The single most common mistake is drawing boxes in the first two minutes. "Design Instagram" is not a spec, it is an invitation to ask questions. Spend the first 5 to 8 minutes narrowing it.

Ask functional questions: Are we designing the photo upload and feed, or also stories, DMs, and search? Pick a core slice and say so out loud: "I will design upload plus the home feed, and treat DMs as out of scope unless you want them." Then ask non-functional questions: expected daily active users, read-to-write ratio, acceptable latency, and consistency needs. Write the answers down where the interviewer can see them.

This is not stalling. Naming scope is the first signal of seniority. A junior tries to build everything and runs out of time. A senior says what they are building and what they are deliberately not building. The same instinct that helps you explain your real projects in 30 seconds applies here: lead with the boundary, then the detail.

Step 2: Capacity estimation, with real numbers

Most candidates skip this or hand-wave it. Do not. Back-of-envelope math tells the interviewer you understand the scale you are designing for, and it directly shapes later decisions like sharding and caching.

Work an example. Say 50 million daily active users, each opening the feed 10 times a day. That is 500 million feed reads per day, roughly 5,800 reads per second on average, and you should assume peak is 2 to 3 times higher, so plan for around 15,000 reads per second. If each user posts once every two days, that is 25 million writes per day, about 290 writes per second. Now the read-heavy nature is obvious, and it justifies a read cache and read replicas later.

Do storage too. If a post row is 1 KB and you store 25 million per day, that is 25 GB per day, around 9 TB per year of metadata before media. Media itself goes to object storage, not your database. Saying these numbers out loud, even rounded, is worth more than a perfect diagram.

Step 3: Components and the request flow

Now draw, and keep it honest. A typical flow: client, load balancer, stateless application servers, a cache layer, a primary database with read replicas, object storage for media, and a CDN in front of static and media content. Add asynchronous workers for anything that does not need to happen in the request path.

Walk one request end to end. "User opens the feed. Request hits the load balancer, routes to an app server. The server checks the feed cache in Redis. On a hit, it returns; on a miss, it queries the database, builds the feed, writes it back to cache, and returns." Concrete request tracing beats a static diagram every time, because it shows you understand how the pieces talk.

This is where HLD and LLD diverge. The HLD LLD interview boundary matters: high-level design is the box diagram and the data flow above. Low-level design is one component in depth, for example the table schema, the cache key structure, or the class design for the feed builder. Good interviewers push from HLD into LLD on whatever you sounded least sure about, so do not bluff a component you cannot detail.

Step 4: Data model

State your entities and their relationships plainly: users, posts, follows, likes. Then choose storage per access pattern, not per fashion. A relational store like PostgreSQL is a perfectly defensible default for users and posts. A follow graph at large scale may justify a separate store. The feed itself is often precomputed and cached rather than computed on every read.

Name your keys and indexes. "Posts table indexed on user_id and created_at so I can fetch a user's recent posts efficiently." If you shard, say the shard key and why: sharding posts by user_id keeps a user's data together but can create hot shards for celebrity accounts, which is a real problem you should flag rather than hide.

Step 5: Caching, and what it costs

Caching is the lever that makes a read-heavy system affordable, but every cache decision has a cost. Say what you cache, the eviction policy, and the invalidation strategy. "I cache the home feed per user in Redis with a 5 minute TTL. On a new post from someone you follow, I either invalidate or accept up to 5 minutes of staleness."

That last clause is the senior move: you named the staleness you are accepting. Caching without mentioning invalidation is the most common shallow answer in this round. Mention cache stampede protection too if reads are heavy: a single popular key expiring can hammer the database, and a lock or staggered TTL prevents it.

Step 6: Queues and asynchronous work

Anything slow or non-critical to the response should be off the request path. Fan-out of a new post to followers' feeds, sending notifications, generating thumbnails, updating counters: push these to a message queue and process them with workers.

Be specific about delivery semantics. "I use a queue for feed fan-out. Workers are idempotent because the queue gives at-least-once delivery, so a retried message must not double-insert a post into a feed." Saying "idempotent" and explaining why earns real credit, because it shows you have run async systems in production, not just read about them.

Step 7: Failure handling

Interviewers will probe what breaks. Have answers ready. What if a database replica goes down? Reads fall back to the primary or another replica. What if the cache is unavailable? Requests degrade to the database with rate limiting so you do not melt it. What if a worker crashes mid-job? The message returns to the queue and a healthy worker retries.

Mention the single points of failure in your own design before the interviewer finds them. "My load balancer is a SPOF as drawn, so in production I would run it in an active-passive pair." Self-auditing your design is exactly the posture that also makes you stronger in a mock interview rubric, where examiners reward candidates who surface their own gaps.

Step 8: Trade-offs, stated explicitly

There is no correct system design, only defensible ones. The candidates who pass are the ones who say "I chose X over Y because of Z, and here is what I gave up." Strong consistency versus availability. SQL versus NoSQL for a given table. Push fan-out on write versus pull fan-out on read for the feed: push is fast to read but expensive for users with millions of followers, so a hybrid that pushes for normal users and pulls for celebrities is often the answer.

If you take nothing else from this checklist, take this: never present a choice as if it were free. Every component you add costs latency, money, or operational burden. Naming that cost is the clearest signal of a senior engineer.

Common mistakes that sink the round

• Designing before scoping. Drawing boxes for a problem you have not narrowed wastes your best 10 minutes.
• Skipping the numbers. No capacity estimate means every later decision looks arbitrary.
• Buzzword stacking. Adding Kafka, Cassandra, and Elasticsearch without justification reads as inexperience, not breadth.
• Silence. This round is graded on your reasoning out loud. A correct design built in silence scores worse than a flawed one you narrated well.
• No trade-offs. A design with no stated cost tells the interviewer you cannot see the cost.
• Ignoring failure. Happy-path-only designs read as someone who has never been on call.

How to actually prepare for this in India

You do not get good at this by watching videos. You get good by designing 8 to 10 systems out loud against a clock, then having someone push on your weak component. Pick canonical problems: a URL shortener, a rate limiter, a news feed, a chat service, a ride-matching system. For each, run the eight steps above and time yourself to 40 minutes.

If your current pay does not match your skill, this round is usually the gap between where you are and where you should be. Before you start applying, it is worth knowing your actual market value so you target the right band, and worth understanding how we structure preparation in our method. The system design round is learnable, and for engineers in the 3 to 6 year range it is often the highest-return thing you can practice.