A system-design answer that fits in 45 minutes

"Design a ride-hailing backend" is not a question, it is a territory. Forty-five minutes is enough to cover one path through it well, or every path badly. Structure is what separates the two, and the structure is the same almost every time.

1. Requirements — five minutes

Establish what you are building before you build it. Functional: which two or three user actions are in scope? Non-functional: how many users, what read-to-write ratio, what latency, does it need to be strongly consistent or is eventual fine? Ask; do not assume. If the interviewer says "you decide", state your assumption out loud and write it down — it becomes the contract for the rest of the answer.

2. Envelope maths — three minutes

Turn the numbers into something you can design against. Ten million daily users, each opening the app five times, is roughly six hundred requests a second averaged, call it three thousand at peak. A hundred bytes per event at a million events a day is a hundred megabytes a day, forty gigabytes a year. Nobody is checking your arithmetic to two decimals; they are checking that you know whether this fits on one machine or needs a fleet.

3. The high-level sketch — ten minutes

Clients, API layer, the two or three services that matter, the data stores, and whatever sits between them. Keep it to boxes you can justify. Every box you draw is a box you may be asked to defend, so do not add a message queue because diagrams usually have one — add it when you can say what it decouples and what happens when it backs up.

4. The data model — five minutes

This is where weak answers show. Name the main entities, the access patterns, and the choice of store with a reason: "reads are by user and time range and are far more frequent than writes, so I'd partition by user ID and keep the recent window in a cache." Choosing SQL or NoSQL without naming the access pattern that drove it is the single most common gap in this round.

5. Stress it — the remaining time

• Where is the bottleneck first? Say it before they ask. Every design has one and pretending otherwise is the least credible thing you can do.
• What happens when a component fails — is the failure mode degraded service or data loss?
• How does it behave at ten times the load? Which part is stateless and scales horizontally, and which part is the problem?
• What are you deliberately not handling, and why is that acceptable for this scope?

Habits that read well

Manage the clock out loud — "we have fifteen minutes; I'd rather go deep on the matching service than sketch everything, is that useful to you?" Interviewers almost always say yes, and it converts a time problem into a collaborative decision. Say "I don't know" when you do not, then say how you would find out. Nobody is expected to have operated every technology they name, and pretending otherwise fails on the second follow-up.

A design with one honest bottleneck named is stronger than a design with none.