1. Design a URL shortener
Clarify: Are links permanent? Can owners edit destinations or create custom aliases?
Follow-up: One short link becomes extremely popular. What happens to your reads, analytics, and destination updates?
Evidence to look for: You separate the redirect path from analytics, explain identifier collisions, and define how an edited destination becomes visible. A cache needs a freshness policy as well as a reason to exist.
2. Design a chat service
Clarify: Is this one-to-one messaging or group chat? What should an offline recipient see later?
Follow-up: A sender reconnects after a timeout and submits the same message again.
Evidence to look for: You distinguish message persistence from delivery, define ordering within a conversation, and explain how a client recognizes a duplicate. A persistent connection alone does not establish those guarantees.
3. Design an API rate limiter
Clarify: Is the limit per customer, user, IP address, or endpoint? Are short bursts acceptable?
Follow-up: Requests arrive through multiple regions while the shared limiter is unreachable.
Evidence to look for: You explain where enforcement happens and what callers experience during failure. You connect any approximate enforcement to the business cost of admitting or rejecting requests.
4. Design an order-notification service
Clarify: Which channels are required, and how late can a notification arrive?
Follow-up: The delivery provider times out after possibly accepting the message.
Evidence to look for: You explain retry ownership, duplicate handling, and how uncertain outcomes are reconciled. Read the worked notification trade-off after attempting the problem yourself.
5. Design a news feed
Clarify: Is the feed chronological or ranked? Do users follow individuals, topics, or both?
Follow-up: A small number of accounts have millions of followers.
Evidence to look for: You explain when feed work happens and who pays its storage and compute cost. You discuss freshness and a skewed follower distribution instead of treating every account as average.
6. Design a file-sharing service
Clarify: Do users upload whole files, synchronize edits, or collaborate simultaneously?
Follow-up: An upload fails halfway through, and the owner later revokes a sharing link.
Evidence to look for: You distinguish file bytes from metadata, explain how interrupted uploads resume, and show where access is checked. Knowing a file's identifier must not automatically grant permission to download it.
7. Design a ticket-booking service
Clarify: Are customers buying assigned seats or general admission? How long does a reservation last?
Follow-up: Two customers try to buy the last seat while the payment provider responds slowly.
Evidence to look for: You identify the operation that prevents double booking and explain reservation expiry, payment uncertainty, and recovery. A diagram with a payment service does not establish who owns the seat.
8. Design a nearby-places search service
Clarify: Are locations static businesses or moving vehicles? How fresh must results be?
Follow-up: A dense city center returns too many candidates for each query.
Evidence to look for: You explain how the search narrows geographically, how results are ranked, and what an indexing delay means for users. Geographic proximity and result relevance are separate decisions.
9. Design a metrics-ingestion service
Clarify: What are the write rate, retention period, and required query latency?
Follow-up: A large customer sends a burst while other customers expect normal service.
Evidence to look for: You explain ingestion limits, tenant isolation, aggregation, and the policy for late data. Show where pressure accumulates when consumers cannot keep up.
10. Design a background-job scheduler
Clarify: Are jobs one-time or recurring? Must a job run at an exact time, or within a window?
Follow-up: A worker crashes after performing the work but before acknowledging completion.
Evidence to look for: You separate scheduling from execution and explain leases, retries, and duplicate effects. State which guarantee your system can offer rather than promising "exactly once" without a mechanism.
11. Design a video-upload and processing service
Clarify: Which formats and playback devices must be supported? When can viewers first watch an upload?
Follow-up: One processing stage repeatedly fails while the original upload remains intact.
Evidence to look for: You describe the processing stages, persisted progress, retry boundaries, and the status shown to the uploader. Explain how you avoid repeating successful work unnecessarily.
12. Design a product-search service
Clarify: Which matters most: text relevance, inventory freshness, personalization, or response time?
Follow-up: Search returns a product that has just sold out.
Evidence to look for: You distinguish the search index from authoritative inventory and define what happens between discovery and purchase. You state where freshness matters enough to require another check.
Make a question harder by changing the constraint
Use the same prompt at different depths. These are practice variations, not universal definitions of engineering levels.
- First pass: Establish requirements, draw a complete path, and explain the main stored state.
- Deeper pass: Trace a failure, defend an alternative, and estimate the bottleneck that drives your choice.
- Broader pass: Add migration, regional failure, operational ownership, and the cost of changing the design without stopping the existing service.
A more demanding answer can use a simpler architecture if it explains why that architecture fits the problem and how it would evolve.
Turn the question bank into a practice loop
Choose one prompt, attempt it without a reference answer, and introduce its follow-up after your first design. At the end, write down the decision you could not defend and rehearse that decision again.
For structured voice practice with a whiteboard and design feedback, explore Revarta's system design practice on a desktop or tablet. Sign in or create an account to see its curated problems; access depends on your plan or available mock credits. The editorial exercises on this page are separate from the in-app catalogue.
For a question about your past experience rather than a hypothetical architecture, practice explaining a system design trade-off you made.
Frequently asked questions
Which system design question should I practice first?
Start with a system whose user action you understand, such as shortening a link or sending a notification. Draw one complete path before adding scale. Then introduce a failure and explain how the system recovers.
Do these questions come from real employer interviews?
These are editorial practice prompts based on familiar system categories. They are not attributed to employers, and their inclusion does not predict your interview question. Ask your recruiter which design format and level of detail to expect.
How many system design questions should I complete?
Use coverage and evidence of improvement rather than a fixed total. Practice different pressures, including read volume, real-time delivery, contested state, and background processing. Revisit a question when you still cannot explain its central decision or failure behavior.
Do I need to write code in a system design interview?
Some rounds emphasize architecture; others include API contracts, data models, or detailed component design. Confirm the format. These exercises focus on architecture and reasoning, so they do not replace coding or low-level design preparation.
Editorial scope
The prompts and review cues are original Revarta preparation material, reviewed November 10, 2026. They are exercises rather than complete reference architectures or an employer scoring rubric.
