Надёжная публикация событий
Вопрос
Сервис заказов должен сохранить заказ и надёжно сообщить о нём другим сервисам. Опишите решение целиком.
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Проблема двойной записи: нет общей транзакции БД и брокера
Outbox-таблица в той же транзакции
Публикатор: polling или CDC (Debezium), at-least-once
Ключ сообщения order_id для порядка
Идемпотентные консьюмеры, ретраи, DLQ, очистка outbox
Что могут спросить следом
- Чем polling хуже CDC?
- Как не опубликовать одно событие дважды двумя публикаторами?
Разбор
Писать в БД и сразу в Kafka нельзя: между двумя операциями процесс может упасть. Поэтому в той же транзакции, что и INSERT заказа, вставляю строку в outbox: тип события, ключ order_id, payload. Публикацию делает отдельный процесс. Простой вариант: раз в секунду выбирает неотправленные строки с FOR UPDATE SKIP LOCKED, отправляет и помечает. Более зрелый: Debezium читает WAL и публикует без нагрузки запросами. Ключ сообщения order_id, чтобы события заказа шли в одну партицию по порядку. Доставка at-least-once, поэтому консьюмеры идемпотентны. Отправленные строки outbox чищу по расписанию, слежу за возрастом самой старой неотправленной записи.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.