У цій статті
Простежте платіжну подію від приймання до дії
В умовному сервісі підписок платіжний постачальник повідомляє застосунок, який активує доступ. Stripe явно документує перевірку підпису, повторні доставки й обмеження порядку подій. Це нагадує вивчати контракт кожного постачальника, не вважаючи один HTTP-запит однією бізнес-операцією.
Запропоноване приймання перевіряє підпис, записує подію в стійкий inbox і підтверджує після збереження. Worker окремо змінює бізнес-стан. Зберігайте ID події, контекст акаунта, стан і спроби разом. Підтвердження означає приймання; в експлуатаційних інструментах воно не має доводити вже успішної активації підписки.
Припускайте недосконале доставлення
Вебхуки запізнюються, дублюються й змінюють порядок. Опитування пропускає коротку зміну або повторно отримує те саме. До підключення бізнес-ефектів задайте ідентичність події, версію джерела й правила порядку.
Підтверджуйте доставлення лише після стійкого приймання. Зберігайте посилання постачальника й контрольовані метадані для повтору, уникаючи секретів і зайвих персональних даних.
Зробіть ефекти ідемпотентними й спостережуваними
Використовуйте сталий ключ ідемпотентності кожної бізнес-команди, прив’язаний до вмісту. Той самий ключ з іншими даними — конфлікт, не повтор. Обмеження БД мають захищати правило за конкурентного виконання.
Якщо після локальної транзакції потрібен зовнішній виклик, відокремте приймання від доставлення через outbox. Відстежуйте очікування, обробку, доставлення, повтор і dead-letter, не змушуючи викликувача чекати іншого постачальника.
Повтор події не має повторювати ефект
Приклад доставки з надійно збереженим станом.
Прийняти
Перевірте вхідну подію та її ідентифікатор.
Зберегти
Зафіксуйте приймання й розпізнавайте повторну доставку.
Обробити
Застосуйте бізнес-ефект із захистом від повторів.
Звірити
Порівняйте очікуваний і фактичний стан після збоїв.
Звіряйте стан, а не лише повторюйте
Повтори розв’язують тимчасові транспортні збої, не невідомий результат чи розбіжність змісту. Додайте обмежені затримки, розбір dead-letter, ручний повтор і звіряння канонічного стану з постачальником.
Призначте власника схем, ключів, лімітів і несумісних змін. Панелі мають показувати запізнілі, завислі й розбіжні записи та безпечний спосіб відновлення.
Складний випадок: дія відбулася, відповідь — ні
Worker активував доступ і впав до позначки завершення. Повтор має розпізнати вже виконану активацію. За можливості фіксуйте ключ операції та зміну стану однією транзакцією. Перевірки перед незахищеним записом замало: два worker можуть одночасно пройти її.
Для віддаленого ефекту локальна транзакція не робить виклик атомарним. Використовуйте ідемпотентність віддаленого сервісу, зберігайте його посилання операції та звіряйте невизначені результати. Тайм-аут означає «невідомо», не обов’язково «невдача». Створіть явний нерозв’язаний стан, не новий ключ для повтору вже можливого успіху.
Підтвердьте приймання, потім контролюйте дію
Спрощений шлях після перевірки підпису. Невизначений віддалений результат звіряється до нової спроби.
Перевірка → стійкий inbox → підтвердження → worker
Бізнес-операцію вже завершено?
Так
- Повернути збережений результат
- Позначити доставлення обробленим; не повторювати дію
Ні
- Закріпити ключ операції → застосувати захищену зміну
- Зберегти успіх; звірити невизначений віддалений результат
Створіть огляд інциденту до першого збою
Оператор має знайти подію й зрозуміти: чи перевірено справжність, чи збережено її, чи були спроби, чи завершено або відкладено для розслідування? Показуйте клас останньої помилки й наступну спробу без секретів і повних платіжних даних. Повтор має мати ті самі бізнес-захисти, що звичайна обробка, і запис ініціатора.
Перевірте дублікати, двох одночасних worker, пізнє старе скасування, збій БД і віддалений тайм-аут після успіху. Після кожного тесту вивчайте бізнес-записи, не лише HTTP-коди. Завдання звіряння порівнює очікувану підписку з авторитетним станом постачальника й позначає відмінності. Це закриває прогалину, нерозв’язну самими повторами.
Джерела й додаткові матеріали
Документацію перевірено .
ЗАПИТАННЯ / РІШЕННЯ
Поширені запитання
Вебхуки завжди кращі за опитування?+
Ні. Вебхуки скорочують затримку й повторне читання; опитування спрощує відновлення та повноту. Критичні інтеграції часто поєднують швидкі вебхуки з періодичним звірянням.