Transactional Inbox
Пост в продолжение к паттерну Outbox. Outbox гарантирует at-least-once. Но кто гарантирует, что сообщение обработают ровно один раз?
Кажется, достаточно просто обрабатывать сообщения на консьюмере, но тут кроется самая важная проблема - дубли. Двойные списания, двойные записи в БД. Consumer не гарантирует exactly-once. Возможна ошибка коммита, OOM или ретрай.
Какое решение? Использовать Inbox
Суть следующая:
1. Создаем таблицу inbox, где будем хранить idempotency_key
2. При обработке события делаем в одной транзакции вставку в две таблицы: inbox и payments.
INSERT INTO inbox (idempotency_key) VALUES ($1) ON CONFLICT DO NOTHING
-- если inserted = 0, значит дубль — выходим
INSERT INTO payments (order_id, amount, status) VALUES ($1, $2, 'pending')
Важно, что захват ключа и бизнес-операция происходят либо вместе, либо никак.
Итого, exactly-once в распределённых системах - это иллюзия, за которой скрывается at-least-once доставка и идемпотентная обработка на каждом узле.
Пост в продолжение к паттерну Outbox. Outbox гарантирует at-least-once. Но кто гарантирует, что сообщение обработают ровно один раз?
Кажется, достаточно просто обрабатывать сообщения на консьюмере, но тут кроется самая важная проблема - дубли. Двойные списания, двойные записи в БД. Consumer не гарантирует exactly-once. Возможна ошибка коммита, OOM или ретрай.
Какое решение? Использовать Inbox
Суть следующая:
1. Создаем таблицу inbox, где будем хранить idempotency_key
2. При обработке события делаем в одной транзакции вставку в две таблицы: inbox и payments.
INSERT INTO inbox (idempotency_key) VALUES ($1) ON CONFLICT DO NOTHING
-- если inserted = 0, значит дубль — выходим
INSERT INTO payments (order_id, amount, status) VALUES ($1, $2, 'pending')
Важно, что захват ключа и бизнес-операция происходят либо вместе, либо никак.
Итого, exactly-once в распределённых системах - это иллюзия, за которой скрывается at-least-once доставка и идемпотентная обработка на каждом узле.