Practice

Architecture Studio

Pick a challenge and build a design one layer at a time. Watch it run, switch a part off, then check it against the goals. The check says what it measured and what would help.

Challenge

People open short links far more often than they make them: 95 of every 100 requests are reads. Most links are opened many times, so 90% of reads could come from a cache. Traffic can double when a link goes viral.

Run it with
Users, send requestsUserssend requests600 a secondApp 1, app server, SLOWApp 1app server99% busySLOWDatabase, no replicaDatabaseno replica52% busy

The lab is busy, so only some requests are drawn as dots, few enough to follow. The numbers still count every request.

  • Users — send requests — healthy — 600 a second
  • App 1 — app server — SLOW — 99% busy
  • Database — no replica — healthy — 52% busy
Lab time 3.0 s
Reads, 95% within
too many failed
Problem: more than 5 in 100 failed
Writes, 95% within
too many failed
Problem: more than 5 in 100 failed
Failed
19.8%
Problem: requests are failing
Cost a month
$220
example prices

Numbers add up:1,900 arrived = 1,488 answered + 368 failed + 44 in progressThe lab checks this sum as it runs, so a counting mistake would show here.

What happened

Nothing yet. Start traffic or run an experiment.

Build your design

Front

Spreads requests across the app servers, and stops using one that has died.

App servers
1

Each one does about 500 requests a second.

Reads

Answers repeated reads from memory, so fewer reach the database.

Database
1

Each shard holds part of the data and takes its share of the writes.

0

Copies that answer reads, and take over if the primary stops.

Writes

The app answers at once; workers save each write to the database later.

Example prices a month: load balancer $20, app server $70, cache $50, database server $150, queue $30, worker $40.

Check your design

The check runs your design for 30 seconds of simulated time under each goal's conditions. A part is switched off after 10 seconds. There is no score: each goal passes or fails.

Share this design

The link holds the challenge and every part you picked. Nothing is saved anywhere else.

What this simplifies

  • Every part's speed is a round example: an app server does 16 ms of work for each request, and a database write takes 16 ms. Real systems vary much more.
  • A request that failed counts as slower than any time limit, so a time goal cannot pass while many requests fail.
  • The load balancer retries a request on the next server after 50 ms when a server does not answer. It stops using a dead server after 5 seconds.
  • A replica takes over 10 seconds after a primary stops. Real failover can be faster or much slower, and can lose writes that were not yet copied.
  • Travel between parts is drawn, but not counted as time.
  • The queue never loses a write. A write it accepts counts as answered before it is saved; the goal on saving covers the wait.
  • The cache is never out of date, and a replica is never behind its primary. Real ones can be, as the caching and replication lessons show.
  • Keys spread evenly across the shards, with no hot key.