Practice system design
Pick a scenario, build your architecture answer, and get senior-level review with interview-readiness scoring - then generate an interview-ready explanation.
Scenarios
10 scenariosURL Shortener
Design a service that turns long URLs into short links and redirects users at high read volume. The classic warm-up: simple to state, deep on read-scaling and key generation.
Real-Time Chat App
Design a messaging system where users exchange messages in near real time across devices, with delivery guarantees and presence.
Notification Service
Design a service that sends email, SMS, and push reliably across many products, tolerating provider downtime and respecting user preferences.
File Upload & Processing
Design a system that accepts user file uploads, scans and processes them safely, and serves them back - the home of object storage, malware scanning, and async work.
Distributed Rate Limiter
Design a rate limiter that caps request rates per client across a fleet of servers - a focused deep-dive on shared state and algorithms.
Form Analytics / Intake Dashboard
Design a platform that collects form submissions from embeddable forms, processes them, and gives staff a queryable dashboard with trends - data privacy and admin access front and center.
Video Streaming Platform
Design a platform that ingests, transcodes, and streams video to a global audience - a YouTube/Netflix-scale read-heavy media problem.
Ride Sharing / Dispatch
Design an Uber-like system that matches riders with nearby drivers in real time and tracks trips - geospatial, real-time, and reliability-heavy.
Payment Processing System
Design a system that takes payments correctly: no duplicate charges, full auditability, safe retries, and reconciliation with the provider.
E-commerce Checkout
Design the checkout path of an online store: cart, inventory reservation, payment, and order fulfillment - correctness and reliability under load.
Study paths
Short concept modules to study the ideas behind the components. Each ends with a mini challenge to apply it.
Request Flow Basics
Trace a request from the client to the database and back. The foundation every system-design answer builds on.
Request Flow Basics
Trace a request from the client to the database and back. The foundation every system-design answer builds on.
Key ideas
- Clients never talk to the database directly - they go through an API
- Start every design by following one request end to end
- Stateless services scale horizontally; push state into data stores
- Name what receives traffic first: client, CDN, load balancer, or gateway
Common mistakes
- Jumping to databases before defining the request path
- Letting the client reach the database directly
- Putting state in the service instead of a data store
Mini challenge: Draw the full path of a single 'create account' request, naming every hop.
APIs, Gateways, and Load Balancers
How traffic enters the system: routing, auth at the edge, rate limiting, and spreading load across instances.
APIs, Gateways, and Load Balancers
How traffic enters the system: routing, auth at the edge, rate limiting, and spreading load across instances.
Key ideas
- A gateway centralizes auth, routing, rate limiting, and request shaping
- A load balancer spreads traffic and routes around unhealthy instances
- Public endpoints need rate limiting from day one
- A versioned API contract keeps clients stable
Common mistakes
- Exposing services directly with no edge layer
- Forgetting rate limiting on public APIs
- Making the gateway a SPOF or a place for business logic
Mini challenge: Add a gateway and rate limiter in front of a service and explain what each rejects.
Databases and Sources of Truth
Choosing a data store, modeling for access patterns, and keeping one clear source of truth.
Databases and Sources of Truth
Choosing a data store, modeling for access patterns, and keeping one clear source of truth.
Key ideas
- Default to relational unless access patterns clearly demand NoSQL
- Clarify read/write ratio early - it drives every data decision
- There is exactly one source of truth; caches and indexes derive from it
- Reads scale with replicas before you reach for sharding
Common mistakes
- Picking NoSQL for 'scale' without known access patterns
- Treating a cache or search index as the source of truth
- Snapshots with no tested restore
Mini challenge: For a social feed, decide SQL vs NoSQL and justify it from the access pattern.
Caching and Read Scaling
Serving hot reads fast without losing correctness: cache-aside, TTLs, invalidation, and stampedes.
Caching and Read Scaling
Serving hot reads fast without losing correctness: cache-aside, TTLs, invalidation, and stampedes.
Key ideas
- Cache hot reads but keep the database as the source of truth
- Every cache needs an invalidation strategy - usually cache-aside + TTL
- CDNs cache static/edge content close to users
- Guard against stampedes with jittered TTLs or request coalescing
Common mistakes
- Caching with no invalidation, serving stale data
- Caching per-user/private responses in a shared CDN
- Synchronized TTLs that all expire at once
Mini challenge: Add a cache to a read-heavy endpoint and describe exactly when it's invalidated.
Queues, Workers, and Async Processing
Moving slow or unreliable work off the request path with queues, idempotent consumers, and dead-letter handling.
Queues, Workers, and Async Processing
Moving slow or unreliable work off the request path with queues, idempotent consumers, and dead-letter handling.
Key ideas
- Queues decouple producers from consumers
- Async work improves latency when users don't need an immediate result
- Consumers should be idempotent - messages can arrive more than once
- Failed jobs need retry limits and a dead-letter queue
- Queue depth and consumer lag must be monitored
Common mistakes
- Adding a queue without a worker to consume it
- Retrying forever with no DLQ
- Ignoring duplicate message delivery
- Using async flow when the user needs immediate consistency
Mini challenge: Design a notification system that can tolerate provider downtime.
Reliability, Retries, and DLQs
Designing for failure: retries with backoff, dead-letter queues, idempotency, and backups you actually test.
Reliability, Retries, and DLQs
Designing for failure: retries with backoff, dead-letter queues, idempotency, and backups you actually test.
Key ideas
- Everything fails; design the failure path, not just the happy path
- Retries need limits and backoff, then a DLQ for poison messages
- Idempotency turns at-least-once delivery into safe-to-replay
- A backup is worthless until you've tested the restore
Common mistakes
- Infinite retries that amplify an outage
- No idempotency, so retries double-apply effects
- Untested backups discovered to be broken during an incident
Mini challenge: Take a payment flow and make every step safe to retry.
Authentication and Authorization
Knowing who a caller is (authn) versus what they're allowed to do (authz), and enforcing both.
Authentication and Authorization
Knowing who a caller is (authn) versus what they're allowed to do (authz), and enforcing both.
Key ideas
- Authentication (who you are) is separate from authorization (what you can do)
- Prefer managed auth over rolling your own
- Check authorization on every privileged action, not just at login
- Secrets live in a manager, never in code or config
Common mistakes
- Conflating authn and authz
- Building custom crypto/session logic
- Checking permissions only at the UI layer
Mini challenge: Add an authorization boundary to an admin tool and list the roles.
Observability: Logs, Metrics, and Traces
Operating what you build: structured logs, metrics, distributed traces, and alerting on symptoms.
Observability: Logs, Metrics, and Traces
Operating what you build: structured logs, metrics, distributed traces, and alerting on symptoms.
Key ideas
- You can't operate what you can't see
- Logs, metrics, and traces answer different questions - you need all three
- Correlation IDs stitch one request across services
- Alert on SLOs and user-facing symptoms, not every blip
Common mistakes
- Logs only, with no metrics or traces
- No correlation IDs across async boundaries
- Alert fatigue from noisy, non-actionable alerts
Mini challenge: Pick the three metrics you'd alert on for a checkout service and why.
Payments and Idempotency
Moving money correctly: idempotency keys, webhooks as the source of truth, audit logs, and reconciliation.
Payments and Idempotency
Moving money correctly: idempotency keys, webhooks as the source of truth, audit logs, and reconciliation.
Key ideas
- Every money-moving call carries an idempotency key
- The provider webhook, not the synchronous response, is the final word
- Every money movement is recorded in an append-only audit log
- A reconciliation job compares your state against the provider
Common mistakes
- No idempotency, so retries double-charge
- Trusting the API response instead of the webhook
- No reconciliation between internal and provider state
Mini challenge: Explain what happens if a payment webhook arrives before your API response.
Architecture Tradeoffs and Interview Framing
Communicating decisions like a senior engineer: requirements first, name tradeoffs, defend choices out loud.
Architecture Tradeoffs and Interview Framing
Communicating decisions like a senior engineer: requirements first, name tradeoffs, defend choices out loud.
Key ideas
- Start from requirements and constraints, not components
- Every choice has a tradeoff - name it before the interviewer does
- Don't over-engineer; match complexity to the requirements
- Be able to explain the request flow and failure modes out loud
Common mistakes
- Listing buzzwords with no reasoning
- Over-engineering a simple problem
- Failing to state assumptions and tradeoffs
Mini challenge: Pitch your URL shortener design in 90 seconds, leading with requirements.