Что такое вебхуки и зачем они нужны: собеседование на системного аналитика по API и Webhooks

В новом эпизоде разобрана работа механизма вебхуков на примере интеграции между медицинской и страховой системой.
Дополнительные материалы к подкасту: getanalyst.ru/podcast/webhooks
Из медицинской информационной системы в страховую подаётся заявка на получение выплат за пациента. Её рассмотрение может занять от сотен миллисекунд до 20 рабочих дней, что создаёт неопределённость и задержки в обновлении статуса.
Традиционные методы опроса страховой системы через API могут быть неэффективными: постоянные запросы могут перегружать систему и не всегда своевременно обновлять статус. Но как быть, если статус заявки может измениться в любой момент и нам нужно доставить его до клиники и пациента оперативно?
На помощь приходят Webhooks - вебхуки. Этот механизм позволяет страховой компании автоматически отправлять уведомления о новом статусе заявки в медицинскую систему сразу после его изменения. Это не только сокращает нагрузку на серверы обеих систем, но и предоставляет актуальную информацию без задержек и лишних запросов.
В этом эпизоде вы узнаете, как работают Webhooks, их преимущества по сравнению с традиционными методами опроса, и как их можно использовать для улучшения взаимодействия между информационными системами.
Актуально для опытных системных и бизнес-аналитиков, кто только знакомится с интеграциями систем или уже давно работает с ними, но еще ни разу не работал с вебхуками.
1:50 - Обсуждение возможных вариантов решения задачи, если вы не знакомы с механизмом вебхуков (Webhooks). Polling и Long Polling и почему.
08:53 - Что такое вебхуки - разбор на примере интеграции медицинской и страховой систем.
10:42 - Как технически реализуется вебхук в рамках интеграции систем, когда в нашу систему-подписчика надо получать уведомления из внешней.
14:54 - Почему механизм Webhooks лучше механизма Polling и других подобных способов опроса внешней системы по таймерам, по расписанию.
20:30 - Как обеспечить работу вебхуков: реализация на стороне системы, которая оповещает о событиях.
26:23 - Почему рекомендуется использовать очереди сообщений для рассылки уведомлений о произошедших событиях при реализации вебхуков. Алгоритм реализации обработки сообщений из очереди.
28:47 - Механизм подписки на вебхуки для потребителей уведомлений.
31:05 - Прием вебхуков на стороне системы-подписчика в очередь и последующая их обработка.
32:27 - Про реализацию метода POST для вебхука на стороне системы-подписчика.
36:08 - Больше примеров задач и бизнес-процессов, где нужны вебхуки.
39:49 - Подведение итогов и рекомендации.

[@04Tural]

Очень интересно! С большим удовольствием слушаю ваши подкасты!

[@GetAnalyst]

Благодарим за обратную связь!

[@user-yx5mj6sm9t]

Очень интересный материал, спасибо! У меня возник вопросистый вопрос по части очереди на стороне страховой компании.. каким образом эти наши заявочки будут отправляться уже в саму мед организацию? (Вряд ли мед организация будет как консюмер выступать.. да и вряд у нас будет реализован пуш механизм для этих консьюмеров.. вот этот момент непонятен) Брокер как то сам будет эндпоинт медицинский вызывать?

[@user-yx5mj6sm9t]

Видимо какой-то обработчик будет срабатывать на стороне страховой?

[@GetAnalyst]

Здравструйте! Спасибо за приятную обратную связь :) Отвечаю на вопрос. У нас есть два сценария. Мед.организация -> Страховая 1. Мед организация отправила запрос на обработку 2. Страховая поставила задачу в очередь к обработке заявок, она в ожидании автоматической или ручной обработки. Страховая -> Мед.организация 1. Заявку обработали. И теперь нам гарантированно надо доставить статус на мед. организацию. 2. Страховая кладет задачу на вызов внешней мед.системы в брокер. Задача находится в брокере, пока мед. система не ответит успехом, либо пока не выполнятся условия исключения задачи из брокера (21 день мед система реагирует ошибками и подобное) Верно поняла вопрос?