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