The short answer
A system design mock interview is a timed practice round where you design a large system, such as a chat app or a URL shortener, while an experienced engineer plays the interviewer. On Revvox it lasts 60 minutes on video with a shared whiteboard, and you are marked 1 to 5 on requirements and estimates, high-level design, data and storage, scale and trade-offs, and communication. The written report arrives within 24 hours. A single round costs ₹2,499 ($32).
What a system design round tests
A system design round is not a quiz about technologies. The interviewer gives you a vague product, such as "design a notification service", and watches how you turn it into a working design in under an hour. There is no single right answer. What they score is the path: which questions you ask first, what you choose to build, what you leave out, and whether you can defend each choice when they push.
For mid-level engineers, the bar is a sound design with sensible storage and a clear request path. For senior and lead roles, the bar moves to trade-offs: where the system breaks first, what it costs to run, how it fails, and how you would change it as traffic grows ten times. The same question can be an easy round or a hard one depending on how far the interviewer pushes, which is why practice at your own level matters.
How it is scored
After the 60-minute round, the interviewer marks each line below 1 to 5 in your written report, due within 24 hours, with notes on what you said and wrote behind each mark. The verdict is one of Strong hire, Hire, Lean hire, Lean no hire or No hire.
| Skill (1 to 5) | What the interviewer looks for |
|---|---|
| Requirements and estimates | You ask before you design, separate must-haves from nice-to-haves, and turn users into rough requests per second and storage. The numbers drive later choices. |
| High-level design | Clear APIs, a small set of components with a reason for each, and a request path the interviewer can follow from client to storage and back. |
| Data and storage | A data model with keys and access patterns, a storage choice that fits them, and a plan for growth: indexes, partitioning, retention. |
| Scale and trade-offs | You find the bottleneck before being asked, compare two options honestly, and say what you would give up. Failure, consistency and cost all count. |
| Communication | You think out loud, check in at the right moments, take hints without losing the thread, and finish on time. |
System design practice questions
Questions in the style of real rounds, written by us. In a mock, the interviewer picks one at your level and follows your answers, so treat these as warm-ups, not a list to memorise.
- Design a link shortener that also shows the owner how many times each link was opened, by country and by day.Key generation without collisions, a read-heavy path with caching, and analytics written asynchronously so redirects stay fast.
- Design the backend for a food delivery app's live order tracking.Location updates at high write rates, fan-out to the customer, and what happens when a rider's phone loses signal.
- Design a notification service that sends email, SMS and push for many internal teams.A queue between producers and senders, per-channel retries, rate limits per user, and how to avoid sending the same message twice.
- Design a chat system for small groups with read receipts.Connection handling, message ordering within a group, storage for history, and how receipts are batched.
- Design a rate limiter that protects a public API across many servers.Where the counters live, the algorithm (fixed window, sliding window or token bucket) and the cost of being slightly wrong.
- Design a search box that suggests completions as the user types.A prefix index, ranking by popularity, keeping suggestions fresh, and latency budgets per keystroke.
- Design a payments ledger for a wallet app.Double-entry records, idempotent writes, reconciliation, and why strong consistency matters here more than elsewhere.
How a Revvox system design mock runs
- Five minutes: the brief. The interviewer states the problem in one or two sentences, the way a real round opens. You are expected to ask questions before drawing anything.
- Ten minutes: requirements and numbers. You agree what the system must do, what it need not do, and rough numbers: users, requests per second, storage per day. Estimates only need to be the right order of magnitude.
- Twenty-five minutes: the design. APIs, the main components, the data model and how a request moves through them. The interviewer interrupts with the questions a real panel would ask.
- Ten minutes: deep dive and failure. One part of the design under pressure: a hot key, a region going down, a queue backing up. This is where senior candidates are separated.
- Ten minutes: feedback out loud. The interviewer tells you how it went while it is fresh. The written report, with marks and next steps, follows within 24 hours.
How to prepare in the week before
Most people over-prepare components and under-prepare the first ten minutes. Interviewers decide a lot from how you scope the problem, so practise saying requirements out loud, agreeing numbers, and writing the API before you draw boxes.
- Learn one storage story well: when you would pick a relational database, a key-value store or a wide-column store, and what each costs you.
- Know the four tools that come up in almost every round: caching, queues, replication and partitioning. Be able to say when each one hurts.
- Practise back-of-the-envelope maths: requests per second from daily users, storage per year, bandwidth for media. Round hard and say your assumptions.
- Pick three classic problems and design each twice, once simply and once for ten times the load. Notice what changes.
- Time yourself. A design that is perfect at minute 70 fails a 60-minute round.
Common mistakes we see
- Drawing a diagram before agreeing what the system must do, then redesigning halfway through.
- Naming technologies instead of reasons: "we use Kafka" without saying what problem the queue solves.
- Skipping the data model. Many designs fall apart on the question "what is the primary key?"
- Treating every requirement as equally hard. Strong candidates name the one hard part early and spend their time there.
- Going silent while thinking. The interviewer can only score what you say and draw.