Опис проєкту
ПерекладУ нас дві системи, які зараз дізнаються про події одна одної лише за розкладом — раз на кілька хвилин один сервіс опитує інший. Це створює відчутну затримку: замовлення вже оформлене, оплата вже пройшла, а друга система дізнається про це лише на наступному циклі перевірки. Хочемо прибрати цю затримку й перейти на миттєві сповіщення про події замість регулярного опитування.
Шукаємо виконавця, який уже налаштовував обмін через вебхуки. З боку джерела подій потрібен механізм, який у момент події (нове замовлення, підтвердження оплати, зміна статусу) одразу надсилає підписаний запит з чіткою структурою даних. З боку приймача потрібен обробник, який перевіряє підпис, відсіює повторні доставки однієї й тієї самої події, ставить завдання в чергу і переживає тимчасову недоступність другої системи завдяки повторним спробам.
Окрема увага — безпеці: обробник має відхиляти підроблені запити, а ключі для підпису повинні змінюватися без зупинки сервісу. Також важливе логування викликів, щоб у разі втрати події можна було швидко розібратися, де вона загубилась.
Що очікуємо на виході:
— Узгоджений перелік подій-тригерів (нове замовлення, оплата, зміна статусу) з описаною структурою даних
— Надсилання підписаних вебхуків з повторними спробами у разі збою
— Обробник на приймальній стороні з перевіркою підпису, захистом від дублів і чергою
— Стислу документацію, за якою наша команда зможе самостійно додавати нові типи подій
Шукаємо виконавця, який уже налаштовував обмін через вебхуки. З боку джерела подій потрібен механізм, який у момент події (нове замовлення, підтвердження оплати, зміна статусу) одразу надсилає підписаний запит з чіткою структурою даних. З боку приймача потрібен обробник, який перевіряє підпис, відсіює повторні доставки однієї й тієї самої події, ставить завдання в чергу і переживає тимчасову недоступність другої системи завдяки повторним спробам.
Окрема увага — безпеці: обробник має відхиляти підроблені запити, а ключі для підпису повинні змінюватися без зупинки сервісу. Також важливе логування викликів, щоб у разі втрати події можна було швидко розібратися, де вона загубилась.
Що очікуємо на виході:
— Узгоджений перелік подій-тригерів (нове замовлення, оплата, зміна статусу) з описаною структурою даних
— Надсилання підписаних вебхуків з повторними спробами у разі збою
— Обробник на приймальній стороні з перевіркою підпису, захистом від дублів і чергою
— Стислу документацію, за якою наша команда зможе самостійно додавати нові типи подій
Веб програмування Готівка, Банківський переказ
