Ada Audits the Latency Budget and Failure Rates

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

foundations
math-foundations
calculation-audit
analytics-ml
beginner
Ada ADA · CALCULATION AUDIT

Ada Audits the Latency Budget and Failure Rates

A cold-chain alert pipeline sits exactly at its 30 s latency target across six stages, while 50,000 events a minute run through three validation checks that fail a combined 0.7% of the time — 350 a minute, or 21,000 an hour. This audit re-derives both ledgers and asks whether raising the watermark from 12 s to 60 s (adding 48 s) really breaks the 30 s promise, and whether those 21,000 dead-lettered events point to a firmware fix rather than a bigger quarantine table.

Companion to the chapter Big Data Pipelines — every number here comes from that chapter.

— stage latency sum, watermark cost, and dead-letter volume, ~5 minutes

A pipeline is two ledgers: one that adds up latency stage by stage, and one that multiplies the ingest rate by its failure fractions. Both decide whether the outputs can be trusted. Every input below is one this chapter's worked examples already stated.

1. End-to-end latency is a sum of stage delays.

The cold-chain alert budget adds its six stages, and it already sits exactly at the 30 s target:

5 + 4 + 3 + 12 + 2 + 4 = 30 s  →  raise watermark 12 → 60 s: 30 − 12 + 60 = 78 s  (48 s over)

2. Dead-letter volume is ingest rate times the combined failure fraction.

At 50,000 events/min the three failure modes add to 0.7%:

0.4 + 0.2 + 0.1 = 0.7%  →  50,000 × 0.007 = 350/min  →  350 × 60 = 21,000/hr

3. The dead-letter path localizes the fault.

Schema failures alone are 50,000 × 0.004, and if 80% trace to one firmware version:

Pipeline question Arithmetic shown Audit result
Cold-chain latency sum (6 stages) 5 + 4 + 3 + 12 + 2 + 4 30 s — meets 30 s target
Total after watermark 12 → 60 s 30 − 12 + 60 78 s
Overrun vs the 30 s promise 78 − 30 +48 s
Combined validation failure rate 0.4 + 0.2 + 0.1 0.7%
Failed / quarantined per minute 50,000 × 0.007 350
Failed / quarantined per hour 350 × 60 21,000
Schema failures per minute 50,000 × 0.004 200
One firmware version's share (80%) 200 × 0.80 160/min (45.7% of failures)

What this means for your design: the watermark is not a free tuning knob — adding 48 s to a budget already pinned at 30 s breaks the promise outright, so you must shorten another stage, split off a fast provisional path, or cut device and network delay so the watermark does not carry the whole uncertainty. And the dead-letter path is not a trash bin: 21,000 failed events an hour is a signal, and when 160 of every 350 (about 46%) trace to one firmware version, the fix is a firmware rollout, not a bigger quarantine table.

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