Ідемпотентність вебхуків: без подвійних платіжних ефектів

Ідемпотентність забезпечує задуманий ефект логічної операції попри повторення доставки чи виконання.

Темні стоси облікових записів, з’єднані індиговими шляхами транзакцій і позначкою звіряння.

Ідемпотентність забезпечує задуманий ефект логічної операції попри повторення доставки чи виконання. Вона не обіцяє, що повідомлення надійде лише раз. Розглядайте приймання, стале збереження, зміну стану й подальшу роботу як окремі межі відмови.

Оберіть правильну ідентичність

Ідентифікатор події розпізнає повторну доставку цієї події. Ідентифікатор платежу пов’язує різні події з бізнес-об’єктом. Ключ ідемпотентності вихідного запиту захищає іншу межу за правилами провайдера. Клієнт і сума не замінюють цих ключів: два законні придбання можуть збігатися. Також визначте дозволені переходи стану.

Збережіть до підтвердження

Перевірте підпис за документацією провайдера й стало збережіть повідомлення або передайте його до надійної черги перед підтвердженням приймання. Атомарно чи рівноцінно пов’яжіть бізнес-зміну та доказ оброблення. Транзакційна вихідна черга допоможе продовжити зовнішні завдання після зупинки. Обмежте доступ і строк зберігання персональних даних у подіях.

Випробуйте повторення та відновлення

Доставте подію послідовно й одночасно, зупиняючи виконавця на кожній сталій межі. Перевіряйте записи, доступ і зовнішні виклики, а не лише відповіді. Пізня подія не повинна нав’язувати старий стан тільки тому, що надійшла останньою. Відстежуйте вік і статус незавершеної роботи. Контрольоване повторне оброблення використовує ті самі захисти й залишає простежуваний слід дії оператора.

Приклад і доказ приймання

Виконавець може зберегти замовлення та зупинитися до позначення події завершеною. Після запуску він отримує ту саму роботу. Спочатку перевірте сталий захист замовлення, потім надання продукту. Друге виконання не може створити додатковий доступ. Якщо виконання бракує, має існувати відновлюване завдання. Запишіть результати окремо з їхніми посиланнями. Це відрізняє подвійний ефект від утраченого наступного кроку. Повторіть спробу з іншим виконавцем, що одночасно бере роботу. Бізнес-гарантія має зберігатися, навіть якщо обидва підтверджують приймання або один повторює після конфлікту. Опишіть також оброблення незворотно хибної події, щоб звичайні повтори не блокували правильних операцій у черзі. Передбачте відповідального за її розбір і безпечне повернення до оброблення після виправлення причини, збереження початкового повідомлення та повної історії спроб.

Stripe — Джерельна документація

Часті запитання

Чи вистачить списку в пам’яті?

Ні. Перезапуски й кілька виконавців потребують спільного сталого доказу.

Чи захищає ідемпотентність провайдера наш вебхук?

Вона захищає його запит; внутрішні ефекти потребують власних контролів.

Чи зберігати всі події безстроково?

Ні. Визначте доречність, потребу розслідування й строк зберігання.

Чи може повторення подвоїти повернення?

Так, без захисту бізнес-операції; перевірте на синтетичних даних.

Як помітити завислу роботу?

За сталим статусом, віком, спробами та незалежним звірянням.

Від задуму до реалістичного обсягу робіт

Поділіться сценарієм користувача, інтеграціями й умовами запуску. Допоможемо підготувати оцінку з припущеннями та винятками.

Переглянути склад послуги →