A system design question gives you a product to build and leaves many decisions open. Your job is to make those decisions explicit, explain the tradeoffs and show how the system meets its requirements.
The questions below cover messaging, feeds, location, payments and media. Each has a starting point, decisions to explain and a follow-up that tests the design. These are practice prompts, with answer outlines and links to detailed explanations.
How to approach a system design interview question
- Clarify the requirements. Pick the users and the few actions the system must support. Ask what can wait and what must happen immediately.
- Estimate the load. Use the number of users, requests and stored objects to identify where scale changes a decision. State your assumptions.
- Define the API and data. Show how a user action becomes a request and what must be stored to complete it.
- Draw a working design. Follow one request through the components before adding more infrastructure.
- Examine a bottleneck or failure. Explain what happens when traffic grows, a dependency slows down or a machine disappears.
Use the follow-up questions to test your answer. If you introduce a queue, explain what happens to a message after a consumer crashes. If you introduce a cache, explain when its value becomes stale.
1. Design a chat application like WhatsApp
Requirements to clarify: One-to-one or group messaging, online and offline delivery, message ordering and delivery receipts.
Answer outline: Keep a connection to online clients, persist accepted messages and route them to recipients. Define an identifier for each message so a retry can be recognized. Store enough delivery state to send messages when an offline client reconnects. Decide which ordering guarantee is needed within a conversation.
Follow-up: A client retries after its connection drops, but the original message was already stored. How do you prevent the recipient from seeing it twice?
Read the WhatsApp chat design.
2. Design a social feed like Instagram
Requirements to clarify: Following, posting, feed generation, ordering and how fresh the feed must be.
Answer outline: Store posts separately from the feed that points to them. Compare building feeds when a post is written with building them when a user reads. Explain why an account with millions of followers changes the cost of distributing a new post. Keep media delivery separate from feed metadata.
Follow-up: A popular account publishes a post. How does your design keep that write from delaying everyone else's feed?
Read the Instagram feed design.
3. Design ride matching like Uber
Requirements to clarify: Driver location updates, nearby-driver search, accepting a trip and what happens when a driver declines.
Answer outline: Index recent driver locations by geographic area. Match a rider with eligible nearby drivers, then make the transition from available to assigned explicit. Location data can tolerate some staleness; assigning one driver to two simultaneous trips needs a stronger rule. Explain how an abandoned request releases an assignment.
Follow-up: Two riders accept the same driver's availability at nearly the same time. Which operation decides who gets the driver?
Read the Uber trip-booking design.
4. Design a rate limiter
Requirements to clarify: What is limited, the time window, whether bursts are allowed and whether the limit applies across all servers.
Answer outline: Choose a limiting policy and define its state. Compare a fixed window, a sliding window and a token bucket for the requirement. Identify the key being limited, such as an account or API key. In a distributed deployment, explain how concurrent requests update that state and what happens when the state store cannot be reached.
Follow-up: A dependency fails. Should the service allow requests, refuse them or use a local fallback? Explain the consequence for this product.
Read the rate-limiting explanation.
5. Design email delivery like Gmail
Requirements to clarify: Sending, receiving, attachments, mailbox access and the delivery guarantees users expect.
Answer outline: Separate accepting a message from delivering it. Persist accepted work before acknowledging it, then process delivery through workers with retry rules. Store attachments separately from message metadata. Explain how a recipient's mailbox is updated and how a temporary delivery failure differs from a permanent one.
Follow-up: A worker sends a message and crashes before recording success. What information lets the next worker retry safely?
6. Design a dating application like Tinder
Requirements to clarify: Profile discovery, geographic filters, likes, mutual matches and chat.
Answer outline: Separate discovering candidate profiles from recording a user's decision. Model a match as the result of two users liking one another. Explain how location and preferences narrow the search, how the application avoids repeatedly showing rejected profiles and when a match should become visible to both users.
Follow-up: Both users like one another at the same time. How do you create one match and notify both users?
Read the Tinder system design.
7. Design video onboarding and streaming
Requirements to clarify: Uploading, supported playback qualities, when a video becomes available and the expected playback experience.
Answer outline: Store the uploaded source, process it into the required formats and track processing status. Publish a video only when the required outputs are ready. Keep the catalogue and playback metadata separate from the large media files. Explain how a CDN brings those files closer to viewers.
Follow-up: Processing fails halfway through an upload's outputs. How do you retry the unfinished work without making a broken video available?
Read the Netflix video-onboarding design.
8. Design an inventory management system
Requirements to clarify: Stock updates, reservations, purchases, cancellations and whether several warehouses sell the same item.
Answer outline: Model stock and reservations, then define the transition that commits a purchase. Separate a reservation's lifetime from the order's status. Explain how concurrent purchases affect the available count, how expired reservations are released and how retries avoid deducting stock twice.
Follow-up: The payment succeeds while the order confirmation times out. How do you reconcile payment and inventory without selling the item twice?
Read the inventory-management design.
Practise explaining your decisions
Choose one question and give yourself a time limit. Draw the design, follow a request through it and answer the follow-up aloud. Review the assumptions you left unstated and the failures you did not handle.
For a guided path, System Design for Interviews covers scaling an online shop and designing applications. Continue with Advanced System Design for deeper database, distributed-system and research-paper study.
To test your explanation in a simulated round, practise with the AI system design interviewer. It is free for signed-in users and produces a scored report. See how the system design judge works.