Start here
Your first web application
A local bakery wants online ordering. Put it online: users must be able to browse the menu and place orders all day long.
Start the exerciseSystem design
Every exercise is graded on what your architecture achieves, not on whether it looks like ours.
Beginner free
Follow a request from the browser to the database and keep a simple app online under real traffic.
0 of 9 passed
- Your first web application A local bakery wants online ordering. Put it online: users must be able to browse the menu and place orders all day long. Client-server modelRelational databasesLatency numbers to know
- Size the virtual machine The team bought a big 32 vCPU machine, yet the site is crawling and the bill is huge. Find what is wrong with the configuration and fix it. Vertical scalingQueueing and utilisationCloud cost optimisation
- Survive a server crash At 10:00 one of your application servers will crash. Nobody is watching the dashboards. Keep the site available anyway. Single point of failureHorizontal scalingLoad balancing
- Serve images to Europe A Montréal photo marketplace is a hit in France. Pages feel slow there because every image crosses the Atlantic. Make images load fast for European visitors. Content delivery networkObject storageLatency numbers to know
- Take the pressure off the database A news site is read far more than it is written. The database is the bottleneck and the budget does not allow a bigger one. CachingCache-asideTime to live
- Launch day A game studio launches at noon and expects four times the usual traffic for an hour. Stay up during the rush without paying for a data centre. Capacity planningQueueing and utilisationHorizontal scaling
- The runtime pays the bill A booking API runs on six Python servers that are already at their limit, and finance wants the bill cut. The team can redeploy the same API in Go, Java or Python. Make it fast and cheaper. Horizontal scalingVertical scalingCloud cost optimisation
- Two servers are not redundancy The shop already runs four servers behind a load balancer, yet at 13:00 a data centre power failure will take zone A offline for an hour. Keep selling. Single point of failureFailoverAvailability and the nines
- The database will crash at 11:00 A ticketing site keeps everything in one database server. At 11:00 its disk will fail. Stay online and do not lose a single ticket sale. FailoverRPO and RTOSynchronous and asynchronous replication
Intermediate
Design a web application that absorbs load, survives a server failure and stays within budget.
- URL shortener Design a service that creates short links and redirects 12,000 visitors per second, with a monthly budget of 2,500 dollars. CachingAuto-scalingBack-of-the-envelope estimation
- Pay only for office hours An HR platform is busy from 9:00 to 18:00 and almost idle at night, yet runs ten servers around the clock. Cut the bill without hurting the morning rush. Auto-scalingElasticityCloud cost optimisation
- Checkout that never waits During flash sales, orders arrive in bursts and the payment step is slow. Accept every order instantly, process them reliably, and never charge a customer twice. Message queuesAsynchronous processingIdempotency
- Too many connections A marketplace scaled its API to 100 servers and now the database refuses connections and reads are slow. Fix the data tier while keeping users' own changes visible. Connection poolingRead replicasRead-your-writes
- Authentication is the bottleneck A partner API checks every request by calling the identity service. Partners now send 6,000 requests per second and the identity service is drowning. Keep every request authenticated. API gatewayJSON Web TokensAuthentication
- Search without melting the database A second-hand marketplace added a search bar. A third of all reads are now text searches with LIKE queries, and the database is on its knees. Inverted indexFull-text searchCQRS
- A slow payment provider Checkout calls a payment provider that answers in 380 ms, fails now and then, and rate-limits you. Customers must get an instant confirmation and nobody may ever be charged twice. Third-party dependenciesAsynchronous processingIdempotency
Advanced
Build distributed systems and choose consciously between consistency, latency and availability.
- A cart that never forgets Shoppers add items to their cart and sometimes see them disappear on the next page. The cart lives in a Cassandra cluster. At 11:00 a node will fail. Make the cart consistent and keep it available. QuorumsCAP theoremPACELC
- Shard the write path A ride-hailing app records every driver's position. Writes have outgrown the biggest database instance available. Scale them out. ShardingPartitioning strategiesConsistent hashing
- Stop the cascade At 10:00 the recommendation service will go down for an hour. Last time, the whole store went down with it. Keep the store selling while recommendations are unavailable. Circuit breakerCascading failuresTimeouts
- Stop the scrapers Bots are scraping every product page of a retailer, and at 14:00 they will multiply by five. Keep real customers fast while blocking the bots. Rate limitingDefense in depthLoad shedding
- Partitions cap your parallelism A clickstream pipeline writes 20,000 events per second into a log. The team added consumers, yet the lag keeps growing and dashboards are hours behind. Make the pipeline keep up. Consumer groupsPartitioning strategiesEvent streaming
- The celebrity problem A social network stores profiles in a key-value database that scales almost without limit. Then a celebrity joins: a quarter of all reads now hit one single key, and requests start failing. Hot keys and hot partitionsPartitioning strategiesCaching
- A replica set that survives a zone Orders live in a three-member document database. At 09:00 the primary will crash, and at 13:00 zone A will go dark for an hour. Keep taking orders and never lose an acknowledged one. Leader electionQuorumsWrite concern and acknowledgement
- A cold cache at peak A sports news site serves 20,000 reads per second from Redis, and the database only sees the few misses. At 15:00, in the middle of the afternoon peak, a release changes the cache key format: every key misses at once. Keep the site up while the cache warms up again. Cache stampedeThundering herdRead replicas
- Absorb the flood at the edge An extortion group has promised to flood a Paris ticketing site at 20:00, right when a concert goes on sale: 1.2 million requests per second for an hour, from a botnet of hundreds of thousands of machines. Keep real fans buying tickets. DDoS protectionAnycastDefense in depth
- Cold starts in the tail A bank moved its account API to serverless functions written in Java. The average latency looks great, yet the mobile team misses its 300 ms p99 target by a factor of three. Bring the tail down without blowing the 3,000-dollar monthly budget. Cold startsTail latencyLittle's law
Expert
Run multi-region platforms with consensus, event streaming and disaster recovery.
- The disaster recovery drill An online pharmacy runs in Montréal, with a standby region in Virginia and DNS failover. The regulator wants proof that it works: at 15:00 the drill switches Montréal off for three hours. Prescriptions keep coming in, and not a single one may be lost. Disaster recovery strategiesRPO and RTOFailover
- Fail over in seconds, not minutes A Paris neobank promises 99.95 % availability. It runs active-passive between Paris and Frankfurt with DNS failover, and its ledger already replicates across three regions. At 15:00 Paris goes down for two hours. Keep the promise. Active-active and active-passiveAnycastHealth checks
- A ledger that outlives its region A North American payments company already serves traffic from Virginia and Montréal behind a global load balancer. Its ledger, a distributed SQL cluster, still runs entirely in Virginia. At 14:00 Virginia goes dark for three hours, and at 15:30 a ledger node crashes while the region is still down. Keep every payment flowing. ConsensusRaft and PaxosQuorums
- No region depends on another An electronics marketplace runs active-active in Paris and Frankfurt, with an order database replicated across three regions. Yet every request, in both regions, calls a pricing and VAT service that only runs in Paris. At 17:00 Paris goes down for two hours. Keep the marketplace selling. Static stabilityMulti-region architectureCascading failures
- Telemetry that survives a region A smart-meter platform ingests 50,000 readings per second from North American homes through two identical regional pipelines, in Virginia and Montréal, behind a global load balancer. Each pipeline was sized for half of the meters. At 14:00 Virginia disappears for two hours and every meter reconnects to Montréal. Do not drop or double-count a single reading. Event streamingPartitioning strategiesConsumer groups
- Exactly-once at 8,000 transfers per second A payments app processes peer-to-peer transfers asynchronously. The team picked a FIFO queue for its exactly-once guarantee, but at 8,000 transfers per second the API is now being throttled. Apply every transfer exactly once, keep up with the flow and stay within a monthly budget of 22,000 dollars. Exactly-once processingIdempotencyDelivery guarantees
- Read locally, write home A Virginia retailer opens in Singapore. By law its orders must be stored in its Virginia database, so today every Singapore request crosses the Pacific, about 220 ms there and back. Make the store feel local in Singapore: fast pages, instant order confirmation, and every order in Virginia within half a minute. Home region and write forwardingLatency numbers to knowCaching
- Capstone: payments across regions Design from scratch the payment API of a European wallet: 8,000 balance reads and 1,000 payments per second at peak, 99.95 % availability, no payment ever lost, and a push notification for every payment. At 16:00 Paris goes down for two hours, and at 17:00 a database node crashes while Paris is still down. Budget: 25,000 dollars a month. Multi-region architectureActive-active and active-passiveConsensus
Architect
Defend an architecture against real business constraints: cost, migration, compliance and teams.
- Five times cheaper, just as reliable A Berlin recipe platform serves 12,000 requests per second at its afternoon peak and pays about 65,000 dollars a month for it. Investors want the bill under 12,000 dollars without losing the SLO: 99.9 % availability, a p99 under 200 ms, and no lost write when the database primary fails at 10:00 or a web server crashes at 13:00. Cloud cost optimisationAuto-scalingCaching
- Contain the blast radius A B2B invoicing platform serves 4,000 companies from one shared stack. Last quarter a schema migration locked the shared database for half an hour and every customer went down at once. The new enterprise contracts cap what one incident may cost. Today a migration will lock the busiest database again at 10:00, for 30 minutes. Contain it, without spending more than today. Cell-based architectureBlast radiusMulti-tenancy
- Plan the 10x launch A game studio opens its new season at 19:00: for two hours its companion app will receive ten times its usual traffic, from 5,500 to 55,000 requests per second, then fall back. Marketing has already announced it. Stay up and fast during the launch, and keep the monthly bill under 13,000 dollars. Capacity planningElasticityAuto-scaling
- Not everything needs consensus A multiplayer game keeps player accounts and purchases in a distributed SQL cluster spread over three regions, and that is the right call: money must never diverge. But the game servers also write every match event into the same cluster, 30,000 writes per second that only feed replays and statistics. The bill has tripled and purchases got slow. Bring the platform under 15,000 dollars a month with a p99 under 250 ms. Polyglot persistenceConsensusPACELC
- Untangle the distributed monolith Three teams own the catalog, cart and reviews services of a fashion store, but the three services still share one database. At 10:00 the reviews team runs a migration that locks that database for an hour, and today that takes the whole store down. The new rule: one team's change must never take down another team's feature. Reviews may vanish from pages during their incident; browsing and checkout may not. Monolith and microservicesConway's lawBulkheads
- Strangle the monolith, safely An insurer's quote engine is a .NET monolith on eight large Windows servers, and its licences eat the budget. The new Go quote service is deployed but has never received production traffic. Finance wants infrastructure under 6,000 dollars a month starting today. The chaos team has planned a drill: at 14:00 the new service crashes for 30 minutes. Strangler fig migrationCanary and blue-green releasesHealth checks