I wanted Cloud Arch Simulator to teach one cloud architecture idea clearly: adding a cache isn't a global fix.
A cache only protects the traffic that actually reaches it. Put it on the wrong branch and the database still gets hammered. Put it in the right place and the load downstream drops sharply. That sounds obvious written down, but it's much easier to grasp after watching a design collapse on a live traffic graph.
Each scenario starts with a broken topology. You deploy it, watch the surge hit, and work out what failed. The tools are familiar: CDNs, caches, load balancers, autoscaling and databases. The goal isn't to cram in the biggest pile of components. It's to place them where they actually change the traffic flow, and still stay inside the budget and latency limits.
The simulation runs on a directed graph instead of firing the full request volume at every node. Traffic enters through an entry point, flows along the connections, and each node gets the sum of its upstream traffic. Offload components (a CDN, a cache, a read replica) absorb a fixed fraction of whatever passes through them and forward the rest downstream. So a node's position in the graph decides how much it shields, not how much you spent on it. Drop a cache on a branch that never carries the heavy traffic and it does nothing.
That positional behavior created a few useful failures during development:
- A Redis cache placed after the overloaded database did nothing.
- A CDN reduced origin traffic, but only for the branch it actually served.
- Autoscaling eventually added capacity, but its cold start was too slow for the first burst.
- Killing the cache mid-surge dumped the full load straight onto the origin.
- A gradual migration could pass most traffic to the new service while a small legacy slice still caused trouble.
The hard part was keeping the model readable without turning the game into a dashboard. Every run shows enough to explain the failure, but you still have to form a hypothesis, change the topology and deploy again. The UI's built with Angular and packaged as a Windows desktop app with Tauri. The board, the live metrics and the YAML mirror all describe the same architecture.
I'm still tuning the line between a useful model and a fun puzzle. A real production system has way more detail, but hiding the core relationship between placement, traffic and failure would defeat the point.
If you've worked on distributed systems: what's the smallest example that made cache placement or traffic routing click for you? A cache stampede, a cold start, a write that bypassed the cache, something else?
Top comments (0)