01 / SYSTEMS · DISCRETE-EVENT PHYSICS

Causality.

Increase sample traffic and find which service becomes a bottleneck.

Agent-assisted deliverySEEDED SIMULATION · #42

Replay3100 ms

Occupied worker slots Calls affected by a faultGlow grows with queue length

Successful requests100.0%180 / 180 completed

Successful request p95526 msEnd to end, including waits

Longest queue wait68 msAcross modeled service calls

Largest mean waitPlannerInspect this service first

The sample models an agent delivery pipeline. Change its conditions, then inspect what happens.

Follow one request

Request number Exact event evidence

Service	Work	Outcome
Gateway	17.0 ms	Completed
Context	82.2 ms	Completed
Planner	163.1 ms	Completed
Tool runner	98.2 ms	Completed
Verifier	60.5 ms	Completed
Evidence	29.3 ms	Completed

Bring your own architecture

Edit this small model or paste an exported architecture object. All branches are required; a join waits for every parent.

{
  "name": "Agent-assisted delivery",
  "nodes": [
    {
      "id": "gateway",
      "label": "Gateway",
      "serviceMs": 18,
      "workers": 4,
      "errorPct": 0
    },
    {
      "id": "context",
      "label": "Context",
      "serviceMs": 70,
      "workers": 4,
      "errorPct": 0
    },
    {
      "id": "planner",
      "label": "Planner",
      "serviceMs": 180,
      "workers": 3,
      "errorPct": 0
    },
    {
      "id": "tools",
      "label": "Tool runner",
      "serviceMs": 95,
      "workers": 3,
      "errorPct": 0
    },
    {
      "id": "verify",
      "label": "Verifier",
      "serviceMs": 65,
      "workers": 2,
      "errorPct": 0
    },
    {
      "id": "store",
      "label": "Evidence",
      "serviceMs": 30,
      "workers": 3,
      "errorPct": 0
    }
  ],
  "edges": [
    {
      "from": "gateway",
      "to": "context"
    },
    {
      "from": "context",
      "to": "planner"
    },
    {
      "from": "planner",
      "to": "tools"
    },
    {
      "from": "tools",
      "to": "verify"
    },
    {
      "from": "verify",
      "to": "store"
    }
  ]
}

Why the replay is reproducible

A time-ordered event queue schedules arrivals and service completions. Each request and service gets the same seeded timing sample when you change a worker count. Parallel branches join explicitly. Faults fail calls whose service intervals overlap the outage. Queued work already reserved may still consume capacity. There are no retries, caching, network transit delays, or production rate limits in this model. Failed request latencies are excluded from p95 and reported through the success rate.

The design draws on deterministic event scheduling and simulation-based systems testing. This is a rehearsal, not a forecast of your production system.

The person behind the project

A note from Luis.

I like drawing software dependencies as clearly as a structural load path. This experiment turns a service diagram into a repeatable queue simulation, so a proposed improvement has something concrete to be compared against.

Who it helps

Engineers exploring a service bottleneck before changing capacity.

Try this

Increase the request rate, replay the scenario, and inspect which queue grows before adding workers.

Start with the lost-response example