Выбор ответа Senior Очереди и события обновлено
Идемпотентный обработчик на SQL
Вопрос
Какой вариант делает обработку платёжного события идемпотентной при повторной доставке?
Попробуйте сами
Выберите вариант, и откроется разбор.
Показать ответ и разбор
Коротко
Правильный ответ: В одной транзакции INSERT ... ON CONFLICT DO NOTHING и начисление. Уникальное ограничение на eventid и вставка в той же транзакции, что и побочный эффект, атомарно отсекают повтор, даже при конкурентной доставке: если вставка ничего не вставила, обработчик выходит.
Варианты ответа
- Сначала
SELECTпо id события и, если записи нет, обработать - Хранить id обработанных событий в Redis без TTL и проверять
- Логировать id события и раз в день проверять логи на дубли
- В одной транзакции
INSERT ... ON CONFLICT DO NOTHINGи начислениеправильный ответ
Разбор
Уникальное ограничение на event_id и вставка в той же транзакции, что и побочный эффект, атомарно отсекают повтор, даже при конкурентной доставке: если вставка ничего не вставила, обработчик выходит. SELECT затем обработка дают гонку: два консьюмера одновременно увидят «нет записи». Отметка в Redis отдельно от БД может разойтись с фактом начисления (упали между ними). Ручная проверка логов это не механизм.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.