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.
