LatencyLab
Simulate your architecture's latency before you build it. Describe the design as a small explicit model, run it thousands of simulated times and see which chain of work users would actually wait on. It is not a profiler, tracer or runtime observer: it works on the design rather than the code, so it applies to any event-driven software. It exists to prevent confident people from shipping bad architecture.
Windows, macOS and Linux. Builds are published on the releases page as they ship.
A design-time latency simulator
You describe a planned or existing architecture as a small, explicit model: the units of work, the events that trigger them and the shared resources they queue behind. LatencyLab executes that model thousands of times with realistic timing variation and out come the numbers a whiteboard cannot give you: how long the flow takes across percentiles, which chain of work actually held each run up and how often each chain is the culprit. The whole workflow is a loop:
Model
Write the architecture down small enough to argue about: tasks, the events that trigger them and the resources they queue behind. Plain JSON, written by hand or built in the composer with no JSON at all. A useful model is often 10 to 20 tasks.
Run
The entry event fires, tasks run on their contexts, queues form where concurrency is exhausted and durations are drawn from the distributions you chose. Hundreds or thousands of times, every run seeded and reproducible.
Read
Every run records the makespan (how long the user waited) and the critical path (the chain of tasks and waits that set the finish time). One run tells you nothing; the spread across runs is the finding.
Change one thing
Raise a context's concurrency, remove a debounce, split a queue. One change at a time, because two changes and a different answer tells you nothing about which one did it.
Compare
Run again on the same seed. The randomness is identical, so a shift in the percentiles or the dominant path is the cost or benefit of the design change, isolated from luck.
What a model is
- System. A name and the entry event that kicks off a run, such as "user clicks Pay".
- Contexts. The things work runs on: a thread pool, a database connection, a browser main thread. Each has one property, concurrency: how many things it can genuinely do at once. Concurrency 1 means everything sent to it waits in line, which is exactly what a single database connection or a UI thread is. This is where queueing (and therefore most surprising latency) comes from.
- Tasks. The units of work: which context each runs on, how long it takes (as a distribution, because real durations vary) and which event it emits when it finishes.
- Wiring. Which events trigger which tasks, optionally after a delay: debounces, retry backoffs, poll intervals. The wiring is the architecture.
You are not modelling your code. You are modelling the shape of the design: what happens, what waits for what and what competes for what.
Any event-driven software
- Because it simulates the design rather than the code, the domain does not matter.
- The same tool models a web checkout calling four backends, a desktop app's UI thread, a fan-out of microservice calls, a mobile flow behind a debounce or an embedded event pipeline.
- It is for anyone making structural decisions about such software: senior engineers, architects, tech leads, at the point where those decisions are still cheap to change.
- If it can be described as work triggered by events, competing for shared resources, it can be modelled.
Change the model, run again on the same seed and you can see exactly what an architectural decision costs before a line of it is written.
One page per question
Everything else lives on its own page, one question each, so nothing here is a wall.
Who it's for
- The roles that make structural decisions which are expensive to undo.
- Stated both ways: for you if and not for you if.
The application
- The idea in four cards, screenshots of a real run and the composer.
- The plain-file outputs every run writes and how to get started.
Using it
- Your first run in six steps, using the shipped Checkout example.
- Then change one thing and run it again, plus why you would pick each setting.
Reading the output
- The screen element by element: histogram, percentiles, critical path, frequency chart.
- The Checkout example narrated end to end, then the six principles.
Why
- The reasoning: latency answered at design time, while the architecture is still cheap to change.
- The same engine produced the numbers in Relativistic Decision Architecture, rerunnable from published seeds.
Download
- One installer per platform: Windows, macOS and Linux, always the newest release.
- Free, local-first, no cloud and no account.