Event-tracker two ways: the durability tradeoff
"Build an event tracker" is underspecified: the same ask yields two different correct implementations. The priority decides — lose no event, or add no latency to the hot path — and no single answer satisfies both.
Problem
"Build an event-tracker" — an underspecified task. The right implementation depends on what matters more: not losing a single event, or not adding latency to the hot path. There is no single answer to both requirements — it's resolved by an architectural choice that has to be made explicitly.
Methodology
Two intentionally different implementations of the same task — as an illustration of the tradeoff.
-
1. UDP variant (
sonaka-event-tracker). Minimal, fire-and-forget. No delivery confirmation, zero latency on the sender side. Applicable when losing some events is acceptable (analytics, sampled metrics) and hot-path load is critical. -
2. HTTP + PostgreSQL variant (
sonaka-event-tracker2). Compact, but with durable storage: confirmed writes, queryable. Applicable when an event is a fact that cannot be lost (billing, audit), at the cost of latency and infrastructure. - 3. The point of this breakdown is not the code — it's the selection criterion: durability vs latency vs operational cost. Two implementations make the tradeoff visible, not just declared.
Artifact
- • github.com/dobryakov/sonaka-event-tracker (UDP, Go)
- • github.com/dobryakov/sonaka-event-tracker2 (HTTP + PostgreSQL, Go)
Two repos side by side — the artifact itself is the argument.
Where it breaks
- UDP loses events on packet loss — that's not a bug, that's the contract; but the team must consciously accept event loss as acceptable.
- HTTP+PG can't sustain the same RPS without scaling — durability costs throughput; the naive expectation "like UDP but reliable" is wrong.
- There's no "right" option outside of context — choosing without an explicit criterion (what's more expensive: a lost event or added latency) is a deferred incident.
For whom and why
If you're making an event-tracking decision, here are two real repositories where the durability vs latency tradeoff is visible in the code itself. Which is more expensive for your case — a lost event or added latency — is the question to answer before the architecture, not after.
Keep reading
About the author
Grigoriy Dobryakov — AI-Driven Head of Engineering
Want to think through durability tradeoffs for your event infrastructure?
Durability vs latency vs operational cost — the decision that shapes how your event pipeline fails under load.
Email meOther breakdowns
An engineering breakdown series: real task → methodology → working artifact → honest breakdown of where it fails.
Back to series →