How playback works

Playback is how a diagram comes to life. It is an illustration driven by your numbers: it shows how a request would travel through the components you drew, and which components the traffic you described would overload. It is not a load test and it does not model real latency or failures — the last section lists exactly what it leaves out.

Two modes#

The toggle in the top-right of the toolbar switches between them.

Both modes loop until you press Stop. Pause freezes everything where it is and Play resumes from the same spot. Switching mode stops playback and clears the Console.

Where Play starts#

Rule-based playback starts at Client components (and HMI Panels, which are the same idea for industrial systems) and walks outward along their connections. Several clients are walked one after another, never mixed together, so the Console stays readable. A client is only ever an origin: nothing else in the diagram calls a client.

If the diagram has no client connected to anything, the Console says so — “No Client component connected to anything — add a Client and connect it to see rule-based playback” — and nothing moves.

How a request walks the diagram#

From the client, the request goes out along a connection to the next component. That component decides what happens next (the special cases are below), the request continues, and when a branch ends the response comes back along the same connections, in reverse. Here is exactly what the Console prints for the diagram above:

Client (client-1) → Backend (backend-1): request
Backend (backend-1) → Database (database-1): request
Database (database-1): responding directly
Database (database-1) → Backend (backend-1): response
Backend (backend-1) → Client (client-1): response

• One step takes about 0.7 seconds and one line appears in the Console per step.
• Fan-out runs in parallel. A component with several onward connections sends to all of them at once, each branch advances on its own, and the component only responds to its caller once the slowest branch has finished.
• Connection direction does not matter. The walk follows a connection from either end, so it does not matter which component you dragged from.
• Order matters in a few places. A component’s connections are ordered by the number you set on each one (right-click it), falling back to the order you drew them. That order decides which branch a cache forwards to on a miss and which target a least-conn load balancer prefers, and it is the order lines appear in the Console.
• Loops are fine. If the walk would revisit a component it is already inside, that component simply responds instead — drawing a cycle is normal and never an error.
• It stays current. At the end of every lap the walk is rebuilt from whatever the diagram is now, so edits you make while Play is running show up on the next lap.

Components that behave differently#

Most components simply pass a request on to everything connected beyond them. A few have a mechanic of their own.

Load Balancer#

A Load Balancer sends each request to one of the components connected beyond it, chosen by its algorithm:

• round-robin takes the targets in turn, one per lap, ignoring how busy they are. The turn is remembered between laps.
• least-conn picks the first target (in connection order) that is below 90% of its capacity, steering away from anything close to its limit. If every target is at or above 90% it still picks one — the last — rather than stalling.

least-conn is an honest approximation, not a live connection count: Diagravo has no running connections to count, so it uses each target’s capacity figure, the same one behind the capacity dots. For the Load-Balanced API template, four laps of round-robin route like this:

Lap 1: Load Balancer (loadBalancer-1): round-robin → routing to Backend (backend-1)
Lap 2: Load Balancer (loadBalancer-1): round-robin → routing to Backend (backend-2)
Lap 3: Load Balancer (loadBalancer-1): round-robin → routing to Backend (backend-1)
Lap 4: Load Balancer (loadBalancer-1): round-robin → routing to Backend (backend-2)

Watch it in the Load-Balanced API template →

Cache and CDN#

A Cache (and a CDN, which is the same idea at the network edge) answers some requests itself. Each request is a hit with probability hitRatePercent — then it responds directly — and otherwise a miss: it forwards the request to its first onward connection only and relays the answer back. With no hit rate set, every request is a hit. With nothing connected beyond it, it always answers directly. A hit:

Client (client-1) → Backend (backend-1): request
Backend (backend-1) → Cache (cache-1): request
Cache (cache-1): HIT — responding directly
Cache (cache-1) → Backend (backend-1): response
Backend (backend-1) → Client (client-1): response

And a miss, where the request carries on to the database:

Client (client-1) → Backend (backend-1): request
Backend (backend-1) → Cache (cache-1): request
Cache (cache-1): MISS — forwarding
Cache (cache-1) → Database (database-1): request
Database (database-1): responding directly
Database (database-1) → Cache (cache-1): response
Cache (cache-1) → Backend (backend-1): response
Backend (backend-1) → Client (client-1): response

The Console counts hits and misses and the Stats tab shows the running hit rate. Automated “crawler” traffic always misses; see attack scenarios.

Data stores and sinks#

Database, Object Storage, Secrets Manager, Memory Chip, Search Index, Monitoring/Logging, Email Service, SMS/Push Notification and Payment Gateway are end of the line. They respond directly and never call onward, even when other components are connected to them. That matters when two backends share one database: the database answers whichever backend asked and never appears to call the other one.

Everything else#

Backend, Proxy, Queue, API Gateway, Edge Gateway, Serverless Function, Auth Service and the rest pass the request on to every onward connection and wait for the answers. A component with nothing connected beyond it responds directly (“no further connections — responding directly”). The Proxy and gateways also do rate-limiting and security checks when traffic is labelled as an attack; that is covered in capacity and attacks.

Reading the Console#

Open it with View → Bottom panel. Each line is one step. The colour is the severity:

• Plain — information: a hop, a response, a routing decision, a cache hit.
• Amber — a warning: a component running hot (70% or more of capacity), or an attack getting through.
• Red — an error: a component over capacity (OVERLOADED), or a simulated breach.

On the canvas, a small label travels with each marker — Request on the way out, Response on the way back — so the animation can be followed without the Console. Attack traffic is coloured and labelled differently (DDoS, SQLi, Hijack, Bot).

Recording a walkthrough#

With Rule-based mode on, Export → Export GIF or Export Video records one full lap of the canvas — the moving markers and capacity dots — and downloads it as a GIF or a WebM video. Both are made in your browser and need no account. They are handy for a README, a Slack message or a slide.

What playback does not model#

Knowing the limits matters as much as knowing the features. Playback does not model:

• real latency, or how long anything takes — the pacing is a fixed animation speed;
• queues filling up over time, retries, timeouts or back-pressure;
• failures: nothing crashes, drops a connection or loses data;
• the contents of anything — a database “responds”, whatever its engine is;
• real concurrency: “active users” is treated as requests per second, a deliberate simplification.