08 / 25 · §5

Надёжная обработка событий

Самое трудное в messaging — не картинка, а гарантии доставки.

Схема: Надёжная обработка событий
Нажми на схему, чтобы открыть в полном размере.

Главное

  • At-least-once — почти всегда. Exactly-once — почти миф. Значит, событие придёт дважды.
  • Idempotency key — каждый consumer и webhook обязан быть идемпотентным. Иначе деньги спишутся трижды.
  • Dual-write problem — пишем в Postgres и шлём в Kafka двумя действиями; второе падает, данные разъезжаются.
  • Outbox pattern — пишем событие в таблицу outbox в той же транзакции, отдельный процесс публикует в брокер.
  • Saga — «транзакция» через 5 сервисов без общего commit: компенсирующие действия вместо rollback.
  • Backpressure — что делать, когда producer быстрее consumer.

Outbox в одной транзакции

BEGIN;
  INSERT INTO orders ...;
  INSERT INTO outbox (type, payload) VALUES ('ORDER_CREATED', ...);
COMMIT;
-- relay читает outbox и публикует в Kafka