Load simulation

Before you spend a cent on infrastructure, Flowright can push synthetic traffic through the design and show you how it behaves — where requests flow, when things autoscale, and where latency builds.

What it models

The simulator walks the traffic edges (the cyan spine) from the Internet entrypoint inward, and for each resource it estimates:

• throughput — requests per second reaching each node
• CPU / utilisation and the resulting autoscaling (ECS services and Auto Scaling Groups spawn and retire instances against their configured thresholds)
• latency — p50 / p90 / p99 as load rises
• errors — saturation and back-pressure once a tier can’t keep up

Nodes light up as traffic reaches them and pods appear and disappear as the design scales.

It reads your real configuration

The simulation isn’t a generic animation — it uses the attributes on your nodes. An ECS service’s CPU, desired/min/max counts, and scaling policy drive how it responds; a Lambda’s memory and the queue depth in front of it shape its throughput. Change a number and the behaviour changes.

Note

Only traffic edges carry load. Reference and association edges (IAM, security groups, subnets) are configuration — they’re ignored by the router, so the model follows the real request path.

It’s a model, not real infrastructure

Nothing is deployed and no requests hit AWS. The point is to compare designs and right-size before you commit — try a bigger instance, an extra cache, a different scaling policy, and see the effect immediately. Pair it with the cost lens to see what a design costs both idle and under load.

Why it matters

The cheapest place to discover that a tier won’t scale is on the canvas, not in production at 2am.