System Design

How to approach it

Hello Interview recommends spending meaningful time upfront on functional and non-functional requirements, data models, and full API designs before touching a diagram. I think this over-indexes on setup. In a 45-minute round, that approach leaves you drawing a rushed, incomplete design at the end, which is the worst possible outcome.

Here is what I do instead. Ask 2 to 4 clarifying questions that actually matter:

• What are the 2 to 4 core functional requirements? (Write them in the corner. Refer back to them.)
• Who is using this and at what scale? (Millions of users? Bursty or steady traffic?)
• How reliable and durable does it need to be? What happens if there is data loss or a failed call?
• Is auth, monitoring, and rate limiting in scope? (It almost always is not. Confirm it and move on.)

Then jot down 3 to 4 model names in a corner of the whiteboard. You almost always have a User. Then whatever the domain needs: Post, Message, Booking, Payment, Metadata. You do not need full schemas. Just the names, to anchor your thinking.

Then start drawing. Do not wait until everything is perfect. Get boxes on the board and talk through the flow as you draw. For API design, say this early and say it often: "I can come back to explicit API design if there is time or if it is something you would like to focus on." The interviewer will tell you if they care. If they do not redirect you, they do not. That phrase alone has saved me from rabbit holes in multiple interviews.

What interviewers actually want

After going through a lot of these rounds I can tell you there are three things that consistently satisfy interviewers:

A completed design

They want to see the full flow for the core use cases, not a beautifully detailed partial design. Cover the main path end to end. If you have time, go deeper. An incomplete design that runs out of time is one of the most common failure modes.

Articulated tradeoffs

For each significant component choice, say why. It is completely fine to present two options and their tradeoffs and then pick one, even with a relatively weak justification. What they do not like is when you refuse to commit. Saying "it depends" and stopping there reads as indecisive. Pick something. They know you are working fast with incomplete information. A weak choice with clear reasoning beats no choice every time.

Basic API design for one or two calls

Once you demonstrate that you can design one endpoint well (the HTTP verb and path, what goes in the body or query params, and the idea of using an auth header for a JWT or session token), interviewers are typically satisfied. I have never had an interviewer really dig into API design, and I wasted time on it in earlier interviews before I figured that out.

Most common topics

A few building blocks come up in almost every design. Having a fluent, well-reasoned answer for each of these will carry you a long way.

Message queues and streams

Kafka is the default choice. Know how partitioning works and when it matters for your design. Redis Pub/Sub and AWS SNS/SQS are also acceptable depending on the context.

Caching

Redis. Know it well. Be ready to discuss cache invalidation strategies and when a cache actually helps versus when it introduces consistency problems.

Exactly-once semantics

Two approaches worth having ready. The first is idempotency keys, which are straightforward and widely applicable. The second is CDC (change data capture) using something like Debezium to stream changes from your data store into Kafka. CDC is powerful and should appear in most of your designs, but it is worth noting that it takes real effort to set up. If an interviewer says they want an MVP by tomorrow, you would skip it and say why.

Storing more data than a SQL table can handle

Your options are NoSQL (DynamoDB, MongoDB), a data warehouse, or SQL sharding. Know the tradeoffs well enough to explain why you would choose one over another given the access patterns in the specific design.

Most common questions

Based on real interviews across multiple loops, these four came up most often or in close variations:

1. Metrics and analytics platform
2. Design Twitter (or a social feed)
3. Design a payment or booking system
4. Design Google Drive

I got those four, or something close to them, the majority of the time. They are worth treating as your core four to nail down thoroughly.

AI chatbot designs

A fifth question that is becoming significantly more common: design an AI chatbot. At minimum, know how a RAG (retrieval-augmented generation) system works conceptually. You do not need to go deep into it unless you genuinely know the space, but you should be able to sketch the basic architecture: embedding model, vector store, retrieval step, LLM call, response generation.