System Design Interview Questions & Answers (2026)
System design interviews test a candidate's ability to architect scalable, reliable, and maintainable systems. They evaluate trade‑off analysis, component interaction, data flow, and performance considerations. To succeed, articulate high‑level architecture, justify choices with concrete metrics, and demonstrate awareness of bottlenecks and failure modes.
20 questions · updated Aug 29, 2026
Quick facts
| Typical rounds | 1–2 design screens, 1–2 deep‑dive follow‑ups |
| Time per question | 45–60 minutes |
| Key focus areas | Scalability, availability, consistency, cost |
| Common tools | Whiteboard, diagrams, simple code snippets |
| Success metric | Clear trade‑off justification and realistic constraints |
Questions
Beginner
Design a URL shortening service like bit.ly.
Start with a high‑level flow: client sends a long URL, service generates a short key, stores mapping in a key‑value store, and redirects on lookup. Use a hash of the URL or a sequential ID encoded in base‑62 for the key. Choose a NoSQL store (e.g., DynamoDB) for low latency reads/writes. Discuss collision handling, read‑through cache for hot URLs, and eventual consistency. Explain how you would scale writes with sharding and handle abuse via rate limiting. A strong candidate mentions TTL for expired links and monitoring of key space exhaustion.
How would you design a real‑time chat application?
Outline components: client SDK, WebSocket gateway, message broker, and persistence layer. Use WebSockets for low‑latency bidirectional communication, backed by a publish‑subscribe broker like Kafka or RabbitMQ to fan‑out messages to participants. Store recent messages in a fast store (Redis) for quick retrieval and archive older history in a relational DB. Discuss scaling the gateway horizontally with sticky sessions or a connection‑aware load balancer. Highlight handling offline users via push notifications and ensuring ordering guarantees through sequence numbers. Strong answers also address encryption and rate limiting.
How would you build a rate‑limiting service for an API gateway?
Implement token bucket algorithm per API key using a fast in‑memory store like Redis. Each request checks the bucket; if tokens are available, decrement and allow; otherwise reject with 429. Use Lua scripts for atomicity. Discuss distributed consistency: either a centralized Redis cluster or a sharded approach keyed by API key. Explain handling burst traffic, setting different limits per tier, and fallback to local cache if Redis is unavailable. Strong answers also cover monitoring usage and dynamic limit adjustments based on load.
Design a leaderboard service for an online game.
Use a sorted set in Redis to store scores per game mode. On score submission, ZADD updates the set; ZRANGE with WITHSCORES retrieves top N players. Persist snapshots to a relational DB for durability and analytics. Discuss sharding by game region, handling ties with timestamps, and cache warm‑up for popular leaderboards. Explain eventual consistency between Redis and DB, and fallback to DB reads if Redis fails. Strong candidates also mention rate limiting to prevent abuse and expiration of seasonal leaderboards.
How would you design a file upload service that supports resumable uploads?
Implement a multipart upload protocol: client splits file into chunks, each sent with a unique upload ID. Service stores each chunk in object storage (S3) with temporary keys. Maintain a manifest in a relational DB tracking received chunks. On completion, assemble chunks server‑side and move the final object to permanent storage. Discuss handling retries, verifying checksum per chunk, and cleaning up stale uploads via background jobs. Strong answers also cover concurrency limits and encryption at rest.
How would you build a service that generates PDFs on demand?
Expose a REST endpoint that receives HTML or template data. Queue the request in a durable broker (RabbitMQ). Worker processes pull jobs, render PDFs using a headless Chromium instance or wkhtmltopdf, and store results in object storage. Return a signed URL to the client. Discuss scaling workers horizontally, handling large payloads with streaming, and timeout handling. Strong answers also mention caching identical requests and sanitizing input to prevent injection attacks.
Explain how you would implement a feature flag system.
Store flag definitions in a central config service (e.g., Consul) and expose them via SDKs that poll for updates. Use a key‑value store for per‑user or per‑segment overrides. Provide rollout strategies: percentage rollout, targeting by attribute, and gradual ramp‑up. Discuss caching flags locally to minimize latency, fallback defaults if the service is unavailable, and audit logging for changes. Strong candidates also mention A/B testing integration and safe rollback mechanisms.
Intermediate
Design a ride‑hailing service (e.g., Uber).
Break down core domains: rider app, driver app, dispatch service, geo‑spatial indexing, and payment. Use a microservice for matching that consumes driver locations streamed via Kafka and stores them in a geohash‑based in‑memory store (Redis). When a rider requests a ride, query nearby drivers with radius search, rank by ETA, and send offers. Discuss eventual consistency between driver status and dispatch, fault tolerance via circuit breakers, and scaling the matching engine horizontally. Include data partitioning by city, handling surge pricing, and ensuring idempotent ride creation to avoid duplicate bookings.
Explain how you would build a distributed cache for a large e‑commerce site.
Propose a two‑tier cache: an in‑process LRU cache for hot items and a distributed cache layer (e.g., Memcached or Redis Cluster) for broader coverage. Use consistent hashing to evenly distribute keys and enable seamless node addition/removal. Discuss cache invalidation strategies: write‑through for updates, TTL for stale data, and explicit purge on inventory changes. Address cache stampede with request coalescing and fallback to the database. Highlight monitoring cache hit ratio, latency, and scaling read replicas to handle traffic spikes during sales events.
Design a notification system that supports email, SMS, and push.
Outline a pipeline: producer writes notification events to a durable queue (Kafka). Consumers fan‑out to channel‑specific workers (email via SMTP, SMS via third‑party API, push via APNs/FCM). Use a template service for content rendering and a retry mechanism with exponential backoff. Store delivery status in a relational DB for audit. Discuss scaling workers horizontally, handling throttling per provider, and ensuring idempotency with unique event IDs. A solid answer also mentions user preferences storage and dead‑letter queues for permanent failures.
How would you build a content recommendation engine for a news site?
Combine collaborative filtering and content‑based signals. Store user‑article interactions in a columnar store (ClickHouse) for batch model training. Serve real‑time recommendations via a microservice that queries precomputed user vectors from a key‑value store and merges with trending article lists from a cache. Use a message queue to update user profiles incrementally. Discuss A/B testing, latency constraints (<100 ms), and fallback to popular articles when personalization data is sparse. Strong answers also cover cold‑start handling and diversity enforcement.
Design a system for storing and querying time‑series metrics.
Use a purpose‑built TSDB like InfluxDB or Prometheus for high‑write throughput. Ingest agents push metrics via HTTP or gRPC, tags are indexed for fast filtering. Implement down‑sampling pipelines to aggregate older data (e.g., 1‑min to 5‑min). Provide a query API that supports range queries, aggregations, and alerting rules. Discuss retention policies, horizontal scaling via sharding on metric name, and compression techniques. Strong candidates also mention federation for multi‑region collection and security via token authentication.
Design a distributed lock service for coordinating microservices.
Leverage Redis SETNX with expiration to acquire a lock, ensuring idempotent release via Lua script. For higher reliability, use etcd or Zookeeper which provide consensus and lease mechanisms. Discuss lock contention, deadlock avoidance by enforcing lock timeout, and re‑entrancy handling. Explain fallback strategies if the lock service becomes unavailable, and how to monitor lock acquisition latency. Strong candidates also mention using the Redlock algorithm for multi‑node safety and handling clock drift.
Design a system for processing large batch jobs like nightly data imports.
Orchestrate jobs with a workflow engine (Airflow) that triggers steps: ingestion, validation, transformation, and load. Use distributed workers (Kubernetes Jobs) to parallelize processing across partitions. Store intermediate data in a durable object store and final results in a data warehouse (Snowflake). Implement idempotent tasks, retries with exponential backoff, and monitoring dashboards. Discuss handling schema evolution, data quality checks, and resource scaling based on job size. Strong answers also cover cost control via spot instances and data lineage tracking.
Advanced
How would you design a video streaming platform like YouTube?
Start with ingestion: upload service stores raw files in object storage (S3) and triggers a transcoding pipeline (FFmpeg on Lambda or EC2) to generate multiple bitrate renditions. Use a CDN to serve chunks via HLS/DASH. Metadata service maintains video info, comments, and recommendations. Discuss scaling storage with sharding by user ID, using a NoSQL DB for video metadata, and a relational DB for relational data like subscriptions. Explain load balancing, cache layers for popular videos, and handling live streaming with low‑latency ingest. Strong answers also cover DRM, content moderation, and cost‑effective tiered storage.
Design a global file storage system similar to Dropbox.
Describe client sync client, metadata service, and chunk storage. Split files into fixed‑size chunks, deduplicate using content hashes, and store chunks in a distributed object store across regions. Metadata service tracks file hierarchy, versioning, and sharing permissions, stored in a strongly consistent DB (e.g., CockroachDB). Use conflict‑resolution algorithms (last‑write‑wins or operational transforms) for concurrent edits. Employ edge caching for frequently accessed files and background replication for durability. Discuss security via end‑to‑end encryption and audit logging. A top candidate also mentions bandwidth throttling and offline sync queues.
Explain how you would design a search engine for product catalogs.
Use an inverted index built with Elasticsearch or OpenSearch. Ingest pipeline extracts product attributes, tokenizes text, and populates the index. Provide a query service that translates user queries into DSL, applies relevance scoring, and returns paginated results. Discuss sharding by product category, replica placement for high availability, and near‑real‑time indexing for inventory updates. Include fallback to a relational store for exact matches and suggest caching popular queries in Redis. Strong candidates also address synonym handling, typo tolerance, and A/B testing of ranking algorithms.
How would you design a system to detect fraudulent transactions in real time?
Create a streaming analytics pipeline: ingest transactions via Kafka, process with Flink or Spark Structured Streaming, and apply a machine‑learning model for fraud scoring. Route high‑risk transactions to a manual review queue. Store results in a fast store for dashboards and a durable DB for audit. Discuss feature engineering, model retraining, and latency budgets (<200 ms). Ensure fault tolerance with checkpointing, and scale horizontally by partitioning on account ID. Strong answers also cover explainability, alert throttling, and compliance logging.
Design a system to handle millions of concurrent video conference streams.
Use a media server mesh (e.g., Janus) or SFU architecture to route streams. Clients publish to regional media nodes; the SFU forwards selected streams to participants, reducing bandwidth. Deploy media nodes in Kubernetes with autoscaling based on CPU and network metrics. Store session metadata in a fast DB for participant lookup. Discuss NAT traversal via TURN servers, latency budgets (<150 ms), and end‑to‑end encryption. Include fallback to CDN for recorded sessions and monitoring of packet loss. Strong candidates also address scaling via geographic sharding and cost optimization with spot instances.
How would you design a social media feed that supports millions of users?
Combine fan‑out on write and fan‑out on read. For high‑profile users, push new posts to followers' timelines stored in a fast cache (Redis) at write time. For regular users, generate timelines on read by aggregating recent posts from followed accounts using a query service backed by a NoSQL store. Use a graph DB to store follow relationships, and employ sharding by user ID. Discuss ranking algorithms, handling deletions, and ensuring eventual consistency. Strong answers also address A/B testing of ranking, spam detection, and cache invalidation on post edits.
Common mistakes
- Skipping high‑level architecture before diving into details
- Ignoring trade‑offs and focusing only on one solution
- Failing to discuss scalability, fault tolerance, and cost
- Over‑engineering with unnecessary components
- Not addressing consistency models or data partitioning
Study plan
- Day 1–2: Review core concepts (CAP theorem, load balancing, caching)
- Day 3–4: Practice 6–8 beginner questions, focusing on clear diagrams
- Day 5–6: Tackle intermediate questions, emphasizing trade‑off analysis
- Day 7–8: Solve advanced questions, incorporate latency and cost metrics
- Day 9: Mock interview with timed whiteboard sessions
- Day 10: Review feedback, refine explanations, and rehearse key phrases
FAQ
How much detail should I include in a system design answer?
Provide a concise high‑level overview, then dive into two or three critical components. Explain why you chose each technology, discuss trade‑offs, and address scalability, latency, and cost. Avoid exhaustive implementation details unless prompted.
Do I need to draw diagrams during the interview?
Yes. A clear diagram helps the interviewer follow your thought process. Use boxes for services, arrows for data flow, and annotate storage choices and protocols. Keep it legible and focus on the parts you’re discussing.
What if I don’t know a specific technology the interviewer mentions?
Acknowledge the gap, describe a comparable alternative you’re familiar with, and explain the criteria you would use to evaluate the unknown technology. Interviewers value reasoning over memorization.
How should I handle follow‑up questions about bottlenecks?
Identify the most likely bottleneck (e.g., database write throughput), quantify it with realistic numbers, and propose mitigation strategies such as sharding, caching, or async processing. Show that you can think ahead about performance.
Is it okay to ask clarifying questions before starting?
Absolutely. Clarify scope, expected traffic, latency SLAs, and any constraints. This demonstrates that you gather requirements before designing, mirroring real‑world engineering practice.
Related
Ready for your next interview?
Download MiPrep AI. Load your resume and the job description. Show up ready.
Free tier · No credit card · macOS 14+ · Windows 10+
Free tier · No credit card · Runs on your Mac or Windows machine