Описание проекта
У нас две системы, которые сейчас узнают о событиях друг друга только по расписанию — раз в несколько минут один сервис опрашивает другой. Это создаёт заметную задержку: заказ уже оформлен, оплата уже прошла, а вторая система узнаёт об этом только на следующем цикле проверки. Хотим убрать эту задержку и перейти на мгновенные уведомления о событиях.
Нужен исполнитель, который уже настраивал обмен через вебхуки. Со стороны источника событий нужен механизм, который в момент события (новый заказ, подтверждение оплаты, изменение статуса) сразу отправляет подписанный запрос с понятной структурой данных. Со стороны приёмника нужен обработчик, который проверяет подпись, отсеивает повторные доставки одного и того же события, ставит задачу в очередь и переживает временную недоступность второй системы за счёт повторных попыток.
Отдельное внимание — безопасности: обработчик должен отклонять поддельные запросы, а ключи для подписи должны меняться без остановки сервиса. Также важно логирование вызовов, чтобы при пропаже события можно было быстро разобраться, где оно потерялось.
Что ожидаем на выходе:
— Согласованный список событий-триггеров (новый заказ, оплата, смена статуса) с описанной структурой данных
— Отправку подписанных вебхуков с повторными попытками при сбое
— Обработчик на приёмной стороне с проверкой подписи, защитой от дублей и очередью
— Краткую документацию, по которой наша команда сможет добавлять новые типы событий самостоятельно
Нужен исполнитель, который уже настраивал обмен через вебхуки. Со стороны источника событий нужен механизм, который в момент события (новый заказ, подтверждение оплаты, изменение статуса) сразу отправляет подписанный запрос с понятной структурой данных. Со стороны приёмника нужен обработчик, который проверяет подпись, отсеивает повторные доставки одного и того же события, ставит задачу в очередь и переживает временную недоступность второй системы за счёт повторных попыток.
Отдельное внимание — безопасности: обработчик должен отклонять поддельные запросы, а ключи для подписи должны меняться без остановки сервиса. Также важно логирование вызовов, чтобы при пропаже события можно было быстро разобраться, где оно потерялось.
Что ожидаем на выходе:
— Согласованный список событий-триггеров (новый заказ, оплата, смена статуса) с описанной структурой данных
— Отправку подписанных вебхуков с повторными попытками при сбое
— Обработчик на приёмной стороне с проверкой подписи, защитой от дублей и очередью
— Краткую документацию, по которой наша команда сможет добавлять новые типы событий самостоятельно
Веб программирование Наличные, Банковский перевод
