Одна система может сама сообщить о событии, а другая — периодически проверять источник. Разбираем различия на примере заказов.
Два способа узнавать о новом заказе
Представим условный интернет-магазин. Покупатель оформил заказ, а складская система должна узнать об этом и начать подготовку товара. Между двумя системами есть связь, но остаётся вопрос: кто первым обращается к другому? От этого зависит способ получения изменений.
При периодическом опросе складская система сама проверяет магазин. При webhook магазин отправляет уведомление о выбранном событии на заранее согласованный адрес. Webhook можно представить как звонок в дверь, а опрос — как регулярный взгляд в почтовый ящик. Аналогия описывает способ узнавать о событии, а не гарантирует доставку или полноту всех данных.
Как работает периодический опрос
API — это согласованный способ взаимодействия программ. При опросе получатель регулярно обращается к нему и выясняет, что появилось или изменилось. Источник может отдавать записи частями, поэтому получение одной порции ещё не означает, что обработан весь список.
В нашем условном примере проверка проходит раз в пять минут. Заказ, появившийся сразу после проверки, может ждать следующего обращения почти пять минут. Это ориентир для выбранного расписания при исправной работе обеих систем, а не универсальная гарантия. Более частые проверки сокращают ожидаемую паузу, но увеличивают количество обращений, даже когда новых заказов нет.
Как работает webhook
Получатель заранее сообщает, какие события ему нужны и куда доставлять уведомления. Когда происходит такое событие, источник отправляет сообщение. Поэтому webhook позволяет узнавать о событиях без постоянных однотипных проверок. Такое различие с опросом описано в документации GitHub.
Само уведомление может содержать подробности или только сведения, по которым получатель затем запросит нужную запись. Это зависит от возможностей источника. Если хочется узнать один показатель раз в день, регулярное обращение к API может быть вполне достаточным. Подписка на все события без разбора лишь создаст ненужную работу.
Почему уведомление ещё надо обработать
Отправка сообщения и успешное выполнение складской операции — разные события. Получатель может быть временно недоступен, сообщение может прийти повторно, а источник может не гарантировать порядок доставки. Например, Stripe отдельно описывает повторные доставки и ограничения порядка событий. Правила одного сервиса нельзя автоматически переносить на любой webhook.
В условном магазине повторное уведомление о том же заказе не должно создавать вторую посылку. Команде важно уметь узнать уже обработанное событие и проверить текущее состояние заказа. Задержка уведомления об оплате также не должна заставлять систему безусловно верить более старому сообщению о состоянии покупки.
Что выяснить перед выбором
Для webhook нужны понятные правила подписки, подтверждения получения, повторной доставки и проверки отправителя. GitHub рекомендует проверять подлинность сообщений, использовать защищённое соединение и предусматривать работу с пропущенными событиями в практиках использования webhook.
Для опроса важны расписание, ограничения API и способ определить, какие изменения уже получены. В обоих случаях полезно знать, как восстановить пропуск за период недоступности. Не стоит выбирать способ только по обещанию «мгновенно»: сначала нужно понять допустимую задержку и последствия потерянного или повторного события.
Когда два подхода работают вместе
Команда может использовать уведомления для быстрой реакции, а периодическую сверку — чтобы находить пропуски. В условном магазине событие помогает начать подготовку заказа, а сверка проверяет, не остались ли необработанные покупки. Это возможная архитектура, не обязательное устройство любого сервиса.
Практический первый шаг — нарисовать путь одного заказа словами: где он появился, кто о нём сообщил, где отмечена обработка и как обнаруживается отсутствие сообщения. После этого проще обсуждать интеграцию с инженером данных. Вопрос о webhook становится конкретным вопросом о доставке изменений между системами.
Как перейти к практике
Если хотите разбирать подобные задачи системно, посмотрите программу Data Engineer для начинающих. Важно учиться связывать устройство системы с потребностями пользователей и проверять ограничения выбранного подхода.
