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.
Build an architecture, push real traffic through it, and watch which part melts first. Then fix it. In 3D, right in your browser.
Add app servers, a cache, read replicas, an async write queue or a CDN. Each part has a real capacity and a monthly cost.
Choose requests per second and the read, write and static-file mix. Requests flow through the pipes in 3D.
See p95 latency, error rate and cost. The overloaded part turns red and starts dropping requests.
Plain explanations with a live simulation or an interactive diagram where it helps, plus what to say in an interview.
Each one opens healthy. Change one thing and see why every component is there.
Creating a short link is rare; following one is constant. Reads outnumber writes many times over.
4,000 req/sOpen →like WhatsApp or TelegramSending 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 LinkedInPeople scroll far more than they post, so the feed is read-heavy.
6,000 req/sOpen →like YouTube or NetflixAlmost 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 saleEveryone 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 cityEvery active driver sends a location update every few seconds, so most traffic is writes.
1,100 req/sOpen →like Instagram or PinterestMost requests are images, served from the CDN, so your servers never see them.
8,000 req/sOpen →like Google search suggestionsEvery keystroke is a request, and it must answer in well under 100 ms to feel instant.
5,000 req/sOpen →like UPI or Stripe checkoutCorrectness beats speed: a payment must be recorded exactly once, before the user is told it succeeded.
800 req/sOpen →like LeetCode or CodeforcesBrowsing problems is cached reads; submitting code is the expensive part.
900 req/sOpen →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 →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.
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.
Yes, it is free, and no account is needed. Everything runs in your browser; challenge progress is saved only on your device.
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.