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