rhobound

Know what a patch costs before you ship it.

A CVE fix to a shared base image adds a few milliseconds in a benchmark. Rhobound predicts what those milliseconds become once the image is running across your fleet — service by service, with bounds, before rollout.

0 35 70 127 55 rps 90 106 rps utilisation of the busiest service: 0.48 → 0.93 what a non-queueing model predicts what the patch actually costs +13 ms +127 ms
One image patch, one architecture, five load levels. The perturbation is identical every time; only utilisation changes. Rhobound’s prediction tracks the measured curve within about 5% across the whole range, including the far end. Figures from a simulated twelve-service architecture.

Blast radius is not a reachability problem

Dependency scanners can tell you which services contain a patched image. That set is not the answer. Two services running the identical image can see a 40 ms regression and a 1 ms regression, because one of them sits at 90% utilisation behind a fan-out and the other does not.

The cost of a change is set by where it lands in the queue, not by how many places it lands.

Rhobound measures the patch once, in isolation, then propagates it through your real service graph using the queueing behaviour of each hop. The output is a per-service impact map, not a pass/fail verdict.

What it predicts

Predicted versus measured latency change, twelve-service simulated architecture. Four services carry the patched image; eight do not.
ServicePredictedMeasuredIgnoring queues
ingress+13.8 ms+13.7 ms+6.3 ms
auth+7.2 ms+7.0 ms+3.5 ms
catalog+6.6 ms+6.7 ms+2.8 ms
payments+6.2 ms+6.3 ms+5.0 ms
shard-b+3.2 ms+4.4 ms+1.0 ms
ledger000

Services in red do not run the patched image at all. They are damaged by propagation — ingress through its call path, shard-b through contention on a database proxy it shares with a patched sibling. Every unaffected service was correctly predicted to be unaffected.

How it works

  1. Measure the change in isolation.

    Differential profiling of the old and new image attributes the regression to specific code paths — TLS handshake, compression, syscall overhead — instead of one aggregate number.

  2. Convert it per service.

    Each service invokes those paths at a different rate. A TLS-terminating gateway inherits most of the cost; a static file server inherits almost none.

  3. Amplify by local queueing.

    A service-time increase raises utilisation, and waiting time grows with it non-linearly. This is the step that separates a harmless patch from an outage.

  4. Propagate through the graph.

    Costs compose along call paths, take the worst case across parallel fan-out, and accumulate at shared downstream dependencies. Retry and timeout loops are solved as a fixed point, which is what surfaces the changes that cascade rather than settle.

Where it is today

The propagation model is built and validated against discrete-event simulation of a synthetic architecture. It identifies the affected set exactly, predicts mean impact within roughly 5% at moderate load, stays accurate to within about 5% up to 93% utilisation, and proves saturation cases arithmetically rather than statistically. Against a model that ignores queueing it is seven times more accurate at normal load and twenty times more accurate near saturation.

Next is calibration against live telemetry — OpenTelemetry traces for topology, arrival rates and service times — and validation against injected latency in real clusters.