При выборе между push-событиями и периодическим опросом в каком случае опрос становится механизмом надёжной сверки состояния?
Периодический опрос предпочтителен как механизм сверки, когда источник не гарантирует надёжную доставку событий, не предоставляет воспроизведение пропущенных изменений или допускает временную недоступность подписчика. Он позволяет регулярно сравнивать фактическое состояние с локальной копией, но обычно жертвует оперативностью и создаёт дополнительную нагрузку.
Push-интеграции появились, чтобы не заставлять потребителей постоянно запрашивать источник и получать одни и те же данные. Событие сообщает об изменении почти сразу и эффективнее использует ресурсы при редких изменениях.
Опрос сохраняет значение из-за практических ограничений распределённых систем: подписчик может быть недоступен, событие может быть потеряно из-за ошибки интеграции, а источник может вообще не поддерживать публикацию событий. Поэтому polling часто используют не как замену событиям, а как reconciliation, то есть периодическое восстановление согласованности.
Предположим, сервис заказов должен поддерживать локальное представление статусов доставки. Если полагаться только на push-события, временная ошибка брокера, подписчика или маршрутизации может привести к пропуску изменения.
Если выбрать слишком частый опрос, возрастут нагрузка на источник, задержки обработки и риск одновременных пиков запросов. Слишком редкий опрос уменьшит нагрузку, но увеличит окно устаревших данных. Кроме того, ответ источника должен позволять понять, какие записи изменились после предыдущей сверки; простая загрузка всего набора плохо масштабируется.
Опрос становится надёжной сверкой, когда источник предоставляет способ получить актуальное состояние или изменения за некоторую позицию: например, по времени изменения, монотонному идентификатору версии или маркеру продолжения. Потребитель сохраняет этот маркер, получает следующую порцию данных и безопасно применяет результат повторно.
Важно различать два режима. Polling изменений извлекает только записи, изменившиеся после известной позиции, а полная сверка периодически сравнивает весь релевантный набор или его сегменты. Первый режим дешевле, второй способен исправить ошибки, возникшие из-за удаления, повреждённой локальной копии или пропущенной границы выборки.
Опрос должен быть идемпотентным на уровне применения данных: повторное получение одной записи не должно ухудшать состояние. Нужны пагинация по стабильному критерию, сохранение прогресса после успешной обработки, ограничение параллелизма, тайм-ауты, экспоненциальная задержка после ошибок и случайное смещение расписания, чтобы экземпляры не обращались к источнику одновременно.
Опрос не восстанавливает порядок бизнес-событий и не сообщает причину изменения. Он даёт актуальное состояние на момент чтения. Поэтому он подходит для синхронизации проекций и периодической коррекции, но не заменяет события, если потребителю нужны все переходы состояния, точное время реакции или бизнес-логика на каждое изменение.
Практичный вариант — сочетать оба подхода: события дают низкую задержку, а polling периодически исправляет пропуски. При этом источник должен поддерживать согласованный способ получения изменений, иначе сверка может пропускать обновления, произошедшие на границе двух запросов.
Платёжный провайдер не гарантирует повторную отправку webhook после длительного сбоя магазина. Интернет-магазин должен обновлять состояние платежей и не оставлять заказы навсегда в статусе «ожидает оплаты».
Рассматривались три варианта. Использовать только webhook — быстро, но ненадёжно при пропущенной доставке. Периодически загружать все платежи — просто концептуально, но дорого и плохо масштабируется. Запрашивать изменения после сохранённого времени или курсора — эффективнее, однако требует от провайдера стабильной семантики фильтрации и обработки пограничных случаев.
Выбрали webhook для оперативного обновления и периодическую сверку платежей по курсору с периодической полной проверкой небольшого временного окна. Повторное применение результата было идемпотентным, а задержка сверки считалась приемлемой для исправления редких пропусков. Такой дизайн не обещал мгновенную реакцию при сбое, зато ограничивал время рассогласования и не зависел от безупречной доставки webhook.
Можно ли считать polling надёжным, если источник возвращает только текущий список объектов?
Не обязательно. Без версии, времени изменения или другого устойчивого признака потребитель не всегда сможет определить, что изменилось между двумя ответами. Особенно опасны краткоживущие записи: объект мог появиться и исчезнуть между опросами. В таком случае нужна поддержка журнала изменений, увеличивающийся курсор или периодическая полная сверка с явной политикой обработки удалений.
Почему запросы по времени изменения могут пропускать данные?
Граница по времени может быть неоднозначной: несколько изменений получают одинаковую метку, часы имеют ограниченную точность, а запись может стать видимой после того, как потребитель уже зафиксировал границу. Надёжнее использовать составной курсор, например пару из времени и уникального идентификатора, либо повторно читать небольшой перекрывающийся интервал. Повторы должны быть безопасны, иначе устранение пропусков создаст дубликаты побочных действий.
Что делать, если при сверке источник меняет данные прямо во время постраничного чтения?
Без стабильного снимка страницы могут дублироваться или пропускаться: элементы сдвигаются, а новые записи появляются между страницами. Решения — читать по монотонному ключу, использовать курсор, предоставленный источником, или работать со снимком версии. Если источник не даёт ни одного из этих свойств, потребитель должен допускать повторы, выполнять последующую повторную сверку и явно принимать ограничение на точность согласования.