codequest / system design
⚡ Built for system design interviews

Break systems before they break you.

Build an architecture, push real traffic through it, and watch which part melts first. Then fix it. In 3D, right in your browser.

  • Live 3D request flow
  • Real p95, error rate and cost
  • Fix-the-AI challenges
Healthy at 4,000 req/s
URL shortener with a cachep95 59 ms · errors 0.0%
How it works

Three steps, no whiteboard.

1

Build

Add app servers, a cache, read replicas, an async write queue or a CDN. Each part has a real capacity and a monthly cost.

2

Push traffic

Choose requests per second and the read, write and static-file mix. Requests flow through the pipes in 3D.

3

Read the numbers

See p95 latency, error rate and cost. The overloaded part turns red and starts dropping requests.

Learn

The core 21 concepts, explained.

Plain explanations with a live simulation or an interactive diagram where it helps, plus what to say in an interview.

  1. 01Horizontal scaling & load balancing
  2. 02Caching
  3. 03Content delivery networks (CDN)
  4. 04Database replication
  5. 05Message queues & pub/sub
  6. 06Latency, throughput & p95
  7. 07Sharding (partitioning)
  8. 08Consistent hashing
  9. 09CAP theorem & consistency models
  10. 10SQL vs NoSQL
  11. 11Rate limiting
  12. 12Back-of-envelope estimation
  13. 13API gateway
  14. 14Real-time: polling, SSE & WebSockets
  15. 15Unique ID generation
  16. 16Idempotency
  17. 17Retries, timeouts & circuit breakers
  18. 18Database indexes
  19. 19Leader election & consensus
  20. 20Multi-region architecture
  21. 21Bloom filters
Start learning →
Famous systems

Classic interview designs you can poke at.

Each one opens healthy. Change one thing and see why every component is there.

like bit.ly or TinyURL

URL shortener

Creating a short link is rare; following one is constant. Reads outnumber writes many times over.

4,000 req/sOpen →
like WhatsApp or Telegram

Chat app

Sending a message is a write, and people send a lot of them, so writes are a big share of traffic.

1,400 req/sOpen →
like X (Twitter) or LinkedIn

News feed

People scroll far more than they post, so the feed is read-heavy.

6,000 req/sOpen →
like YouTube or Netflix

Video streaming

Almost all traffic is video chunks, which never change once uploaded: perfect for a CDN.

10,000 req/sOpen →
like a concert ticket drop or a Big Billion Days sale

Flash sale

Everyone arrives at the same second, and many of them try to buy (write) at once.

5,500 req/sOpen →
like Uber or Ola in one city

Ride hailing

Every active driver sends a location update every few seconds, so most traffic is writes.

1,100 req/sOpen →
like Instagram or Pinterest

Photo sharing

Most requests are images, served from the CDN, so your servers never see them.

8,000 req/sOpen →
like Google search suggestions

Search autocomplete

Every keystroke is a request, and it must answer in well under 100 ms to feel instant.

5,000 req/sOpen →
like UPI or Stripe checkout

Payments

Correctness beats speed: a payment must be recorded exactly once, before the user is told it succeeded.

800 req/sOpen →
like LeetCode or Codeforces

Online code judge

Browsing problems is cached reads; submitting code is the expensive part.

900 req/sOpen →
Challenges

Hit the targets. Some designs came from an AI.

Each challenge gives you traffic, a latency goal and a budget. Two of them start from a confidently wrong design an AI suggested. Find the bottleneck and fix it.

Start the challenges →
  1. 1Launch daybeginner
  2. 2The read-heavy feedbeginner
  3. 3The AI architect's designAIintermediate
  4. 4Image floodintermediate
  5. 5The overbuilt AI designAIintermediate
FAQ

Questions

What is a system design simulator?

A sandbox where you assemble an architecture (load balancer, app servers, cache, database, replicas, queue, CDN), send traffic through it, and see what happens: p95 latency, error rate, cost, and which component saturates first. It turns interview whiteboard talk into numbers you can test.

How accurate are the numbers?

They come from a simple, documented queueing model with fixed capacities per component (for example 400 requests/s per app server). Real systems vary. The goal is intuition for bottlenecks and trade-offs, not sizing production hardware.

Is it free? Do I need an account?

Yes, it is free, and no account is needed. Everything runs in your browser; challenge progress is saved only on your device.

Does it help with system design interviews?

It trains the reasoning interviewers look for: estimating load, spotting the bottleneck, and explaining why a cache, replica, queue or CDN helps (and when it does not). The famous-systems pages map to classic interview questions such as designing a URL shortener or a news feed.