System Design Interview Questions by Level: Junior, Mid-Level, Senior, and Staff
Not every system design interview evaluates the same thing.
A junior engineer may be asked to design a URL shortener and explain why a cache would help. A mid-level engineer could receive the same question but be expected to estimate traffic, choose a database, and handle key collisions.
A senior engineer may need to discuss multi-region deployment, consistency, failure recovery, and operational trade-offs. A staff engineer could be pushed further into migration strategy, organizational boundaries, cost, and the long-term evolution of the platform.
The question may look identical. The expected answer is not.
This is why preparing from one enormous, unstructured list of system design questions can be misleading. Candidates often spend time on problems that are far above or below the depth required for their target role.
A better approach is to organize your preparation around the level you are targeting.
This guide breaks system design interview questions into four groups:
- Junior engineers
- Mid-level engineers
- Senior engineers
- Staff engineers
For a broader collection covering every difficulty tier, see the complete pillar guide: 64 System Design Interview Questions, Ranked From Easiest to Hardest.
The goal here is different. Instead of simply listing questions, we will examine what interviewers expect from candidates at each engineering level.
What Changes as You Move Up the Engineering Ladder?
System design interviews become harder with seniority, but not simply because the systems become larger.
The most important change is the depth of reasoning expected from you.
A junior candidate is usually evaluated on whether they understand fundamental building blocks.
A mid-level candidate must connect those building blocks into a scalable architecture.
A senior candidate must anticipate failures, challenge assumptions, and defend architectural trade-offs.
A staff candidate must think beyond the immediate system and consider its interaction with teams, platforms, migrations, business constraints, and long-term technical strategy.
A simplified progression looks like this:
| Level | Primary expectation |
|---|---|
| Junior | Understand the basic components and produce a workable design |
| Mid-level | Build a scalable end-to-end system and explain major trade-offs |
| Senior | Handle ambiguity, failures, correctness, and operational complexity |
| Staff | Shape the problem, evaluate long-term consequences, and lead the design discussion |
Your preparation should reflect this progression.
Junior-Level System Design Interview Questions
Junior engineers are not normally expected to design a globally distributed platform from first principles.
Interviewers are more interested in whether you can:
- Clarify basic requirements.
- Identify the main entities.
- Define simple APIs.
- Choose reasonable storage.
- Understand caching and load balancing.
- Estimate basic traffic and storage.
- Explain how the system could scale beyond one server.
The best junior-level questions usually focus on one dominant concept.
1. Design TinyURL
A URL shortener is one of the best starting points for system design preparation.
The core workflow is simple:
- A user submits a long URL.
- The system generates a short identifier.
- The identifier is stored with the original URL.
- Requests to the short URL are redirected.
A junior candidate should be able to discuss:
- The API for creating and resolving links.
- Generating unique short keys.
- Handling collisions.
- Storing URL mappings.
- Caching frequently accessed links.
- Expiring links when necessary.
Do not overcomplicate the first version. Start with a single service and database, then explain how load balancers, replicas, and caches could be introduced as traffic increases.
2. Design Pastebin
Pastebin extends the URL-shortening problem by adding larger content, expiration, and access control.
Important questions include:
- Should paste content and metadata live together?
- How will pastes expire?
- How will private pastes be protected?
- Where should large text objects be stored?
- How can popular pastes be served quickly?
This problem teaches an important system design lesson: different types of data may require different storage strategies.
3. Design an API Rate Limiter
A rate limiter controls how many requests a user or client can send during a given period.
Junior candidates should understand the basic algorithms:
- Fixed window
- Sliding window
- Token bucket
- Leaky bucket
The interview is not only about naming an algorithm. You should explain where counters are stored, how limits are associated with users, and what response is returned when the limit is exceeded.
A simple in-memory solution is acceptable initially. You can then introduce a shared store such as Redis when multiple application servers need access to the same counters.
4. Design a Unique ID Generator
Distributed systems frequently need identifiers for users, orders, posts, messages, and transactions.
The problem appears easy until several machines must generate IDs simultaneously.
A junior-level discussion may compare:
- Auto-incrementing database IDs
- Random UUIDs
- Timestamp-based identifiers
- Preallocated ID ranges
- Snowflake-style IDs
Focus on uniqueness first. Ordering, clock drift, and coordination can be introduced as deeper follow-up topics.
5. Design Typeahead Suggestions
A typeahead service returns suggestions while a user is entering a search query.
The design introduces:
- Prefix lookup
- Tries and prefix indexes
- Popularity ranking
- Caching
- Latency requirements
- Updating trending queries
The most important lesson is that the system cannot scan every possible query after each keystroke. It needs a data structure or precomputed index that supports fast prefix retrieval.
6. Design an API Gateway
An API gateway sits between clients and backend services.
A foundational design should explain how it handles:
- Request routing
- Authentication
- Rate limiting
- Logging
- Response aggregation
- Protocol transformation
This question helps junior engineers understand how clients interact with a microservice architecture without calling dozens of internal services directly.
What a Strong Junior Answer Looks Like
A good junior-level answer does not need to include every distributed-systems technique.
It should demonstrate a clear thought process:
- Clarify what the system must do.
- Define the main API operations.
- Choose a simple data model.
- Draw the initial architecture.
- Identify the likely bottleneck.
- Explain one or two ways the design could scale.
Candidates preparing for their first system design interview can begin with Grokking System Design Fundamentals and then progress to the original Grokking the System Design Interview.
Mid-Level System Design Interview Questions
Mid-level engineers are expected to move beyond isolated components.
Your design should include a complete flow from the client request to storage, processing, and delivery. You should recognize common bottlenecks without waiting for the interviewer to point them out.
Interviewers may expect you to discuss:
- Read-heavy versus write-heavy workloads.
- Database partitioning.
- Replication.
- Cache placement and invalidation.
- Asynchronous processing.
- Message queues.
- Eventual consistency.
- Basic failure recovery.
- Trade-offs between different designs.
The questions at this level often involve familiar consumer products.
1. Design Twitter
The central challenge in Twitter is generating a user’s home timeline.
Two common strategies are:
Fan-out on write: When a user posts, the system pushes the post into followers’ timelines.
Fan-out on read: When a user opens the application, the system retrieves recent posts from everyone they follow.
Fan-out on write improves read latency but creates enormous write amplification for accounts with millions of followers. Fan-out on read avoids those writes but makes timeline retrieval more expensive.
A strong mid-level candidate should recognize that a hybrid strategy may work best.
2. Design Instagram
Instagram introduces media upload, processing, storage, and delivery.
Your design should separate:
- Media metadata
- Original image or video files
- Derived formats and thumbnails
- Feed-generation data
Application servers should not repeatedly serve large media files. Object storage and a content delivery network are better suited for that workload.
Other useful discussion areas include privacy, upload retries, feed generation, and handling popular posts.
3. Design Facebook Messenger or WhatsApp
A messaging service requires more than storing messages.
You should consider:
- Persistent connections
- Message routing
- Delivery acknowledgments
- Offline delivery
- Conversation history
- Message ordering
- Retries and deduplication
- Multi-device synchronization
The phrase “exactly-once delivery” should be used carefully. In practice, messaging systems often combine at-least-once delivery with idempotency and deduplication.
4. Design Dropbox
Dropbox tests both server-side and client-side reasoning.
Important concepts include:
- Breaking files into chunks.
- Uploading only changed chunks.
- Deduplicating identical data.
- Synchronizing files across devices.
- Handling concurrent updates.
- Maintaining version history.
- Storing metadata separately from file content.
The client plays a significant role because it monitors local changes and communicates them efficiently to the server.
5. Design Uber
Uber combines geospatial search with frequently changing state.
The system needs to:
- Receive driver-location updates.
- Find available drivers near a rider.
- Match drivers with trips.
- Track trip state.
- Calculate estimated arrival times.
- Handle sudden regional demand spikes.
A mid-level candidate should be comfortable discussing geohashes or another spatial partitioning technique, but the conversation should not end there. You must also explain how the location index stays current and how matching requests avoid conflicts.
6. Design Yelp or Nearby Friends
This question focuses on finding entities within a geographic area.
Potential approaches include:
- Geohashing
- Quadtrees
- Grid-based indexes
- Spatial database indexes
The design should account for uneven density. A geographic cell in a rural area may contain almost nothing, while a similarly sized cell in Manhattan may contain thousands of businesses or users.
7. Design Ticketmaster
Ticketmaster introduces temporary reservations and strong correctness requirements.
The system must prevent two customers from purchasing the same seat.
Important topics include:
- Seat-locking mechanisms
- Reservation expiration
- Waiting rooms
- Handling flash traffic
- Payment failures
- Idempotent booking operations
- Releasing abandoned reservations
This question helps distinguish systems where eventual consistency is acceptable from systems where it could create serious business problems.
8. Design a Notification System
A notification platform may deliver:
- Push notifications
- Emails
- SMS messages
- In-app notifications
A good architecture separates notification creation from delivery by placing events on queues. Independent workers can then process different channels.
The system should also respect user preferences, retry temporary failures, prevent duplicates, and enforce provider-specific rate limits.
What a Strong Mid-Level Answer Looks Like
A strong mid-level candidate should be able to:
- Complete the end-to-end design.
- Estimate the dominant workload.
- Explain the main read and write paths.
- Select storage based on access patterns.
- Use queues for work that does not need to happen synchronously.
- Identify hotspots and single points of failure.
- Compare at least two possible approaches to the central problem.
The original Grokking the System Design Interview is especially relevant at this stage because it combines system design fundamentals, recurring trade-offs, and classic interview problems.
Senior-Level System Design Interview Questions
Senior candidates are expected to take ownership of the discussion.
The interviewer may deliberately leave the prompt vague. Rather than asking for every requirement individually, you should identify the assumptions that materially affect the architecture.
Senior interviews tend to emphasize:
- Failure modes.
- Multi-region operation.
- Data consistency.
- Idempotency.
- Observability.
- Backpressure.
- Capacity planning.
- Operational complexity.
- Security and privacy.
- Cost-aware architecture.
- Migration and rollout strategies.
Simply drawing more boxes does not make an answer senior-level. Depth comes from anticipating what could go wrong.
1. Design Google Docs
Real-time collaborative editing requires multiple users to update the same document concurrently.
The key problem is convergence: all clients must eventually agree on the same document state, even when operations arrive in different orders.
A strong discussion may include:
- Operational transformation
- Conflict-free replicated data types
- Operation logs
- Document snapshots
- Cursor and presence updates
- Reconnection after network failure
- Version history
- Permission changes during a session
Senior candidates should explain which updates require durability and which can be treated as temporary presence information.
2. Design ChatGPT
Designing ChatGPT combines conventional application infrastructure with large-model inference.
The product layer may require:
- Authentication
- Conversation history
- Usage limits
- Billing
- Streaming responses
- Safety enforcement
The model-serving layer introduces:
- GPU scheduling
- Request batching
- Model routing
- Token streaming
- Context management
- KV-cache management
- Capacity and cost control
The interviewer may not expect a detailed explanation of model training. A strong candidate clearly defines the scope and focuses on the online serving system.
3. Design a Distributed Cache
A distributed cache such as Redis introduces several difficult concerns:
- Partitioning
- Replication
- Eviction
- Expiration
- Cache invalidation
- Hot keys
- Cache stampedes
- Node failure
- Rebalancing
A senior candidate should discuss what happens during partial failure, not merely describe the happy path.
For example, when an expired popular key receives thousands of simultaneous requests, those requests may all hit the database. Request coalescing, staggered expiration, and stale-while-revalidate are possible protections.
4. Design a Payment System
Payments are dominated by correctness rather than raw scale.
Important concepts include:
- Idempotency keys
- Immutable transaction records
- Double-entry ledgers
- Payment state machines
- Reconciliation
- Webhook retries
- Duplicate events
- Refunds and chargebacks
- Unknown transaction outcomes
A network timeout does not prove that a payment failed. The request may have succeeded while the response was lost. The architecture must preserve this uncertainty and resolve it safely.
5. Design Amazon S3
An object-storage system must provide extraordinary durability while serving huge volumes of reads and writes.
A senior-level design should address:
- Object and bucket metadata
- Data partitioning
- Replication or erasure coding
- Checksums
- Multipart uploads
- Versioning
- Lifecycle management
- Corruption detection
- Background repair
- Hot partitions
- Regional failures
The metadata plane and object data plane should be considered separately.
6. Design a Metrics and Monitoring System
Monitoring systems ingest large volumes of time-series data.
Important concerns include:
- High-throughput ingestion
- Metric labels and cardinality
- Time-based partitioning
- Downsampling
- Retention
- Aggregation
- Query performance
- Alert evaluation
- Late-arriving data
- Regional collection
One of the most important discussions is cardinality. A seemingly harmless label such as a unique user ID can produce an unsustainable number of time series.
7. Design a Code Deployment System
A deployment platform coordinates changes across large fleets of machines or containers.
A strong design should include:
- Build artifacts
- Deployment manifests
- Canary releases
- Blue-green deployments
- Health checks
- Progressive rollout
- Automated rollback
- Audit logs
- Configuration management
- Regional sequencing
The senior-level challenge is not merely deploying the new version. It is limiting the blast radius when that version is defective.
What a Strong Senior Answer Looks Like
Senior candidates should lead rather than follow.
That means:
- Narrowing an ambiguous problem.
- Prioritizing the most important quality attributes.
- Making assumptions explicit.
- Identifying failure scenarios before being prompted.
- Explaining operational consequences.
- Choosing the deep dive that best demonstrates judgment.
- Acknowledging where the design creates future complexity.
Engineers targeting senior and L5/L6 roles can use Grokking the System Design Interview, Volume II for more advanced distributed-systems problems and deeper trade-off analysis.
Staff-Level System Design Interview Questions
Staff-level interviews are not simply senior interviews with larger numbers.
The candidate is expected to reason across systems, teams, and time horizons.
A staff engineer should be able to discuss:
- Platform boundaries.
- Ownership between teams.
- Incremental migrations.
- Build-versus-buy decisions.
- Long-term data models.
- Cross-region architecture.
- Compliance and security.
- Cost and organizational constraints.
- Standardization versus team autonomy.
- How the system evolves over several years.
The interviewer may care more about how you frame the problem than about the final diagram.
1. Design a Stock Exchange
A stock exchange requires deterministic ordering, low latency, and strict correctness.
The design should cover:
- Order submission
- Sequencing
- Order books
- Matching engines
- Market-data distribution
- Persistence and replay
- Risk controls
- Failure recovery
- Auditability
Partitioning by financial instrument can improve scalability, but each order book needs a clear source of authority.
2. Design a Distributed Lock Manager
Distributed locking introduces:
- Consensus
- Leases
- Session expiration
- Leader election
- Fencing tokens
- Split-brain prevention
- Clock and network uncertainty
A staff candidate should understand why acquiring a lock is not enough. A paused or partitioned client might continue operating after its lease has expired. Fencing tokens can help downstream resources reject stale owners.
3. Design a Distributed Job Scheduler
A global scheduler must trigger jobs at the correct time, distribute work, and recover from failures.
Challenges include:
- Sharding schedules.
- Leader election.
- Worker coordination.
- Duplicate execution.
- Missed schedules.
- Long-running jobs.
- Retries.
- Backpressure.
- Time-zone handling.
- Disaster recovery.
The candidate should distinguish between guaranteeing that a job is dispatched and guaranteeing that its business effect occurs only once.
4. Design Apache Kafka
Kafka is best understood as a distributed append-only log rather than a conventional queue.
A staff-level discussion may cover:
- Partitioning
- Consumer groups
- Offset management
- Replication
- Leader election
- Retention
- Log compaction
- Rebalancing
- Delivery semantics
- Cross-region replication
The design should also consider how Kafka would be operated as a shared organizational platform without allowing one workload to destabilize everyone else.
5. Explain Amazon Dynamo
Dynamo provides a rich case study in availability-oriented storage.
Core topics include:
- Consistent hashing
- Replication
- Quorum reads and writes
- Vector clocks
- Sloppy quorums
- Hinted handoff
- Read repair
- Merkle trees
At staff level, do not just define these mechanisms. Explain why Dynamo chose them and which workloads are compatible with those trade-offs.
6. Explain Cassandra
Cassandra combines Dynamo-inspired distribution with an LSM-tree-based storage engine.
A strong discussion may include:
- Partition keys
- Tunable consistency
- Commit logs
- Memtables
- SSTables
- Bloom filters
- Compaction
- Tombstones
- Repair
- Hot partitions
The schema must be designed around queries. Poor partition-key selection can undermine an otherwise scalable architecture.
7. Explain Google File System and Bigtable
These systems show how infrastructure components can be composed.
Google File System is optimized around large files, sequential access, append-heavy workloads, and frequent machine failure.
Bigtable builds a distributed, sorted storage abstraction while relying on other infrastructure for persistent storage and coordination.
The broader staff-level lesson is that architecture is shaped by workload assumptions. A design that is excellent for one environment may be inappropriate for another.
What a Strong Staff Answer Looks Like
A staff-level candidate should be able to:
- Reframe the prompt around business and technical priorities.
- Establish architectural principles.
- Identify the interfaces between major subsystems.
- Explain how multiple teams could own and evolve the system.
- Propose an incremental path rather than a risky rewrite.
- Compare technical complexity with operational and organizational costs.
- Recognize when the system should use an existing platform instead of building a new one.
- Discuss how the architecture behaves during rare but severe failures.
Staff interviews are less about producing the largest possible diagram and more about demonstrating durable technical judgment.
The Same Question Can Be Asked at Every Level
Consider the instruction:
Design a URL-shortening service.
A junior candidate may focus on the API, short-code generation, database schema, and cache.
A mid-level candidate may add traffic estimates, partitioning, replication, expiration, analytics, and abuse prevention.
A senior candidate may discuss global routing, multi-region consistency, disaster recovery, hot-key protection, observability, and safe migrations.
A staff candidate may ask whether the organization should build a shared link-management platform, how several product teams would integrate with it, how privacy policies would be enforced, and how the service could migrate from an existing system without breaking billions of links.
The prompt stayed the same.
The evaluation level changed.
This is why memorizing one “correct” architecture is not enough. Your answer must reflect the depth expected from the role.
How Many Questions Should You Practice?
You do not need to complete every system design question ever published.
A more effective preparation plan is:
Junior candidates
Practice five to eight foundational problems deeply.
Mid-level candidates
Practice approximately ten to fifteen problems covering social feeds, messaging, file storage, geospatial search, booking, and notifications.
Senior candidates
Practice fifteen to twenty problems, with additional attention to payments, infrastructure, observability, collaboration, storage, and failure handling.
Staff candidates
Practice fewer problems at greater depth. Add production case studies and distributed-systems papers to your preparation.
The complete 64-question system design roadmap can help you select problems that match your target level.
For every problem, use three passes:
- Learn: Study the architecture and central trade-offs.
- Reconstruct: Design the system again without looking at the solution.
- Defend: Explain failures, alternatives, costs, and why your decisions fit the requirements.
The third pass is where interview readiness develops.
Choosing the Right System Design Preparation Path
Your preparation resources should match your current level.
Newer engineers may begin with Grokking System Design Fundamentals to build familiarity with scalability, databases, caching, replication, partitioning, messaging, and other architectural building blocks.
Junior and mid-level candidates can continue with the original Grokking the System Design Interview, which applies those concepts to classic interview questions.
Senior and staff candidates should add Grokking the System Design Interview, Volume II, where the emphasis moves toward more complex distributed systems, deeper failure analysis, and defensible architectural decisions.
Candidates working with a limited preparation window can also use the System Design Interview Crash Course as a structured review of system design frameworks and modern design problems.
The broader DesignGurus System Design Interview Guide can serve as a central reference for frameworks, concepts, questions, and study resources.
Final Takeaway
The best system design preparation is not based on solving the greatest possible number of questions.
It is based on practicing the right questions at the right depth.
Junior engineers should build confidence with focused, single-concept systems.
Mid-level engineers should learn to connect components into scalable end-to-end architectures.
Senior engineers should anticipate failures, defend trade-offs, and account for operational complexity.
Staff engineers should shape the problem, guide long-term architecture, and reason across systems, teams, and organizational constraints.
As you move up the engineering ladder, the interviewer becomes less interested in whether you know a particular component and more interested in whether you can make sound decisions under uncertainty.
That is the real progression from junior to staff-level system design.