Разбор 08

Event-tracker двумя способами: UDP fire-and-forget против HTTP+PostgreSQL

Как сделать tradeoff durability vs latency видимым, а не декларируемым — через две намеренно разные реализации одной задачи.

CTO Architect Tech Lead

Проблема

«Сделай event-tracker» — недоопределённая задача. Пока не зафиксированы критерии (durability vs latency), агент угадывает — как с ERP без постановки в разборе #11 или без clarify в spec (#12). Правильная реализация зависит от того, что важнее: не потерять ни одного события или не добавить латентности в горячий путь. Один ответ на оба требования не существует — это архитектурный выбор, который надо проговорить явно.

Методика

Две намеренно разные реализации одной задачи — как иллюстрация tradeoff.

1. UDP-вариант (sonaka-event-tracker). Минимальный, fire-and-forget. Нет подтверждения доставки, нулевая латентность на стороне отправителя. Применимо, когда потеря части событий допустима (аналитика, семплируемые метрики), а нагрузка на горячий путь критична.
2. HTTP + PostgreSQL-вариант (sonaka-event-tracker2). Компактный, но с durable-хранением: подтверждённая запись, возможность запроса. Применимо, когда событие — это факт, который нельзя терять (биллинг, аудит), ценой латентности и инфраструктуры.
3. Суть howto — не код, а критерий выбора. Durability vs latency vs операционная стоимость. Две реализации делают tradeoff видимым, а не декларируемым.

Артефакт

github.com/dobryakov/sonaka-event-tracker (UDP, Go)
github.com/dobryakov/sonaka-event-tracker2 (HTTP + PostgreSQL, Go)

Два репо рядом — сам артефакт говорит за себя.

Подпись серии

Где ломается

UDP теряет события под потерей пакетов — это не баг, это контракт; но команда должна явно решить, что потери приемлемы.
HTTP+PG не держит тот же RPS без масштабирования — durability стоит пропускной способности; наивное ожидание «как UDP, только надёжно» неверно.
Нет «правильного» варианта вне контекста — выбор без явного критерия (что дороже: потерянное событие или добавленная латентность) — это отложенный инцидент.

Для кого и почему

Если вы принимаете архитектурное решение по event-tracking — здесь два реальных репозитория, где tradeoff durability vs латентность виден в коде, а не на слайде. Что дороже для вашей задачи: потерянное событие или добавленная задержка — это вопрос, который надо ответить до, а не после архитектуры.

Нужна помощь в выборе архитектуры для вашей системы событий?

Проектирование event-driven систем с явными tradeoff и документированными критериями выбора — не «как модно», а под ваши требования по надёжности и нагрузке.

Написать на почту

Другие разборы

Серия инженерных разборов: реальная задача → методика → работающий артефакт → честный разбор, где он ломается.

К серии →