Build systems that don't fall over.

Your blog just went viral. In four minutes, traffic spikes 50×. Your architecture is one server wired straight to a database — and it is about to collapse in front of everyone.

Cloud Arch Simulator is a reverse tower-defense puzzle for people who actually build software. You inherit a broken cloud architecture, figure out why it dies under load, and redesign it before a timed traffic surge — and a chaos event — decide whether you were right. Then you learn to size the next one before you build it.

No fictional tech. No hand-waving. Real patterns, real tradeoffs, real consequences.

The loop

• Inherit & diagnose — every scenario starts from a real, broken topology. Deploy it, watch it saturate, and read the failure.
  
• Architect — drag CDNs, caches, load balancers, autoscaling groups, message queues and databases onto the board, then wire how traffic flows.
  
• Deploy & survive — a live surge (up to 120×) hits your design, then chaos strikes: instances die, caches get squeezed, replicas fall behind, whole availability zones go dark.
  
• Get scored — on SLA compliance, budget efficiency, and how clean your infrastructure is. Ranks from C to S. Beat the client's contract, or get your contract terminated.

First size it. Then build it.

Real architecture starts before the diagram — with a napkin. Estimation contracts hand you a product in plain words ("eight million users, six sessions a day, fifteen images a feed") and make you derive the numbers everything else hangs on: peak requests per second, read/write ratio, storage growth. Lowball the estimate and you under-provision — then the real traffic arrives and buries you. It's the half of the job that happens before the first server: the back-of-the-envelope that separates engineers who can start a design from those who stare at a blank page.

Real architecture, real tradeoffs

Every component behaves like its real-world counterpart:

• Positional offload that actually matters — a cache only shields what's downstream of it. Put it in the wrong place and it protects nothing.
  
• Reads are not writes — your cache absorbs one curve and passes the other straight through to the database. Watch both needles.
  
• Replicas serve the past — scale reads across replicas and some hand back stale data. The user who just posted reloads and their comment is gone. Send what must be fresh to the source; let the rest lag. Availability can be perfect while the answer is still wrong.
  
• A dead cache doesn't take its misses with it — they stampede downstream, raw. Survive the thundering herd.
  
• Message queues buy time, not capacity — accept the burst now, drain the backlog before it's due.
  
• Autoscaling has a cold start — it won't save you if you don't buffer the burst while it spins up.
  
• Retries amplify what they touch — the "resilience" chips the last consultant installed are why the outage got worse.
  
• Availability zones are blast radii — when us-east-1a goes dark, everything inside it dies together.
  
• Gradual migration — split traffic by weight to strangle a legacy monolith without taking it down.

Your canvas is infrastructure-as-code, both ways: edit the diagram and the YAML updates live — edit the YAML and the diagram follows.

Watch it hold — or burn

This isn't a spreadsheet. A CRT-oscilloscope readout traces your latency in real time, data-pipe cables pulse with live traffic, overloaded nodes spark and redline, and a three-stage alert system (Yellow → Red → Collapse) screams as your SLA breaks. A correctness readout flags the requests that came back wrong even when nothing technically "failed" — the stale read that passed every health check. Your budget drains by the second while you're down. Every design decision is legible at a glance.

A career of 25 contracts

Climb from Junior Dev to Tech Lead to Principal Architect across 25 scenarios drawn from the incidents that actually happen:

• The Viral Blog — survive a 50× read-heavy spike without breaking the bank.
  
• First Writes — the client shipped comments. Discover why your cache can't save the database anymore.
  
• Ghost Server — half your traffic is dying somewhere. Find the box nobody remembers.
  
• Black Friday — a 120× flash crowd, and autoscaling that's too slow to save you alone.
  
• Edge Eclipse — your CDN provider posts "investigating elevated errors". The origin eats the raw internet.
  
• Stampede — the cache that carried you dies mid-finale, and its misses arrive all at once.
  
• The CFO's Knife — the system is healthy; the bill is not. Cut two-thirds of it without bleeding.
  
• Strangler Fig — migrate a dying monolith to microservices, live, without downtime.
  
• Read Your Writes — you scaled the database with replicas and availability is flawless. So why does a customer's own order vanish the instant they place it?
  
• Flash Order Storm — the tour of the decade goes on sale. Take every order — and pay the backlog debt before midnight.
  
• Region Down — both availability zones fail tonight, one after the other. Payments must not notice.
  
• Midnight Surge — New Year's Eve. The migration is half done, the botnet wakes with the fireworks, and everything that can fail, will.

Mastery is optional. Passing isn't gated.

Hints are always available — tiered from a nudge to a full recipe — and every level can be finished by anyone who can read a card and watch a run fail. But S-ranks are earned hint-free, and at Principal rank the game stops being predictable: the chaos schedule shifts every attempt, the failure targets whatever hurts your design most, and redeploys start costing real money. Plan, don't grind.

Who it's for

Software engineers, SREs, students, and anyone who wants to feel how distributed systems break — and hold. You'll size a system from a one-line brief, then build it to survive the worst night of its life. If you liked untangling a system diagram at 2 a.m., this is the game version, minus the pager.