AMQP Throughput and Reliability Calculation Audit

AMQP Throughput and Reliability Calculation Audit

Ada re-derives this chapter’s own numbers step by step, at full precision

ADA · CALCULATION AUDIT

AMQP Throughput and Reliability Calculation Audit

A 50-robot order fleet clears one order every 45 s, so each robot handles 80 orders/hr and the fleet tops out near 4000 orders/hr — short of the 10,000/hr peak — while a 5 s broker crash on the transient path can drop $250,000 of orders. Persistence and manual acknowledgment each buy that safety by spending throughput or latency. This audit re-derives every ceiling and asks whether the ack-versus-persistence call is philosophy, or simply the ledger these numbers spell out.

Companion to the chapter AMQP Reliability Patterns — every number here comes from that chapter.

— latency-to-throughput ceilings, ack overhead, and loss cost, ~5 minutes

Every reliability knob in this chapter — persistence, manual ack, prefetch — buys safety by spending throughput or latency, and the numbers say exactly how much. Each figure below is one the chapter already stated; I only carry the division through.

See the relationship before changing it

The figure reads from left to right. The blue card is broker write latency. The middle card applies this page's rule. The green card is single-connection ceiling. Walk the arrows once: set the input, apply the rule, then read the result with its unit.

The retained audit below checks several chapter fixtures. This model keeps those stated values fixed and changes only broker write latency, so the numeric fixture does not switch without explanation.

Walk the arrows. Persistence latency lowers the per-connection ceiling while protecting acknowledged orders.

Derive the baseline in four named moves

1. 1

   Name the input. The chapter baseline is 10 ms.

2. 2

   Name the relationship. throughput ceiling = 1,000 ms/s / write latency

3. 3

   Substitute with units. 1,000 / 10 = 100 msg/s

4. 4

   Read the result. Keep the unit beside the value. Use it only inside the technical boundary on this page.

Predict, then change broker write latency

Try Predict the direction of throughput ceiling = 1,000 ms/s / write latency. Test another broker write latency, then compare single-connection ceiling.

Broker write latency

10 ms

Chapter baseline

Single-connection ceiling

Observe Persistence latency lowers the per-connection ceiling while protecting acknowledged orders. Reset broker write latency to 10 and compare single-connection ceiling.

Explain Persistence latency lowers the per-connection ceiling while protecting acknowledged orders.

Check yourself

What should you do before trusting a moved-control result?

Answer: Predict its direction, apply the shown relationship, keep the units, and reset to the worked baseline.

What does this small model leave out?

Answer: Only broker write latency moves here. Field effects named in the technical boundary stay fixed.

Honesty note. This teaching model changes only broker write latency. It is not a field prediction.

Try

Choose Calculate for 50 robots, one order every 45 s, a 10 ms durable write, and a 5 s broker crash.

Observe

The ledger shows 4000 orders/hr fleet capacity, a 20x persistence penalty, and $250,000 exposed on the transient route.

Explain

Persistence lowers per-connection throughput because each acknowledgement waits for disk, yet it protects the high-value orders that a 5 s volatile outage loses.

Technical boundaries

For the durable order path, excluded from this fixed arithmetic are broker contention, network jitter, redelivery storms, storage failure, or correlated consumer outages.

1. Latency sets a hard per-connection throughput ceiling.

If a message cannot clear until its round-trip of L milliseconds completes, one connection tops out at T = 1000 / L messages per second:

disk (L = 10 ms): 1000 / 10 = 100 msg/s  |  memory (L = 0.5 ms): 1000 / 0.5 = 2000 msg/s  →  2000 / 100 = 20×

That 20× gap is the cost of writing each persistent message to disk instead of holding it in memory.

2. Manual ack is cheap when processing dominates; the fleet ceiling is set by processing time.

A 45 s order plus a ~50 ms ack round-trip wastes only 0.05 / 45.05 of the time, and each robot clears 3600 / 45 orders per hour:

Reliability question	Arithmetic shown	Audit result
Persistent throughput ceiling (10 ms disk)	1000 / 10	100 msg/s per connection
Transient throughput ceiling (0.5 ms memory)	1000 / 0.5	2000 msg/s per connection
Persistence throughput penalty	2000 / 100	20× slower
Per-robot order rate	3600 / 45	80 orders/hr
50-robot fleet capacity	50 × 80	4000 orders/hr (below 10,000 peak)
Manual-ack overhead per message	0.05 / 45.05	0.11% (negligible)
Lost orders per 5 s crash (transient)	50 × 5 × $1000	$250,000

What this means for your design: the ack-versus-persistence decision is not philosophy, it is this ledger. Persistence cuts the per-connection ceiling twentyfold, so route only the messages that must survive — the orders worth $250,000 a crash — through the durable path and keep high-volume telemetry transient. Manual ack costs 0.11% when processing dominates, so use it freely for critical work. And note the 4000 orders/hr fleet ceiling comes from the 45 s processing time, not the broker: to reach the 10,000/hr peak you scale consumers, not reliability knobs.

Every number above is taken from the chapter’s own examples and re-derived step by step.