Breakdown 08

Event-tracker two ways: the durability tradeoff

The right implementation depends on what matters more: not losing a single event, or not adding latency to the hot path. There's no one answer — this is an architectural choice that has to be made explicitly.

CTO Architect Tech Lead

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.

Series signature

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

Demonstrates engineering thinking through tradeoffs, not "here's my solution." For an architect or CTO, this signals maturity: the person designs from requirements, not from a favorite stack.

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 me

Other breakdowns

An engineering breakdown series: real task → methodology → working artifact → honest breakdown of where it fails.

Back to series →