[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-sync-loop::ru":3,"gloss-cluster-sync-loop::ru":26,"gloss-next-sync-loop::ru":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"sync-loop","integration","Петля синхронизации","Петля синхронизации возникает, когда две системы уведомляют друг друга об изменениях: запись в одну порождает событие, интеграция применяет его ко второй, эта запись порождает своё событие, и изменение отражается туда-обратно, пока что-нибудь его не остановит. Это характерный отказ двусторонних интеграций, и заметить его приближение трудно: каждый отдельный переход ведёт себя ровно так, как задумано.\n\nСимптомы приходят раньше диагноза. Журнал аудита заполняется правками, за которыми не стоит ни один человек. Лимит запросов, которого месяцами хватало с запасом, выбирается за ночь. Отметки времени изменения обновляются по всему набору данных, и следующий инкрементальный запрос — тот, что просит всё изменённое с прошлого прогона, — возвращает все записи вместо той горстки, которой действительно касался человек, а проблема объёма расползается на всех потребителей ниже по потоку. В худшем варианте петля не быстрая, а медленная — одно эхо на интервал опроса, — и потому днями выглядит как обычная активность.\n\nРазорвать петлю значит дать записи происхождение. Помечайте изменения, сделанные интеграцией, их источником — отдельная учётная запись, флаг на записи, маркер в метаданных изменения, — и пусть слушатель отбрасывает всякое событие, чей источник он сам. Сравнивайте перед записью: значение, которое уже совпадает, не должно порождать запись, а значит, и событие; одна эта привычка снимает большинство петель, потому что большинство откликов — пустые операции. Если источник отдаёт версию или ревизию записи, действуйте по версии, а не по факту того, что запись тронули.\n\nЗатем поставьте границу. Потолок на число записей по одному объекту внутри окна и оповещение по объёму записей, а не по ошибкам, превращают петлю из инцидента, найденного по счёту или по жалобе, в инцидент, пойманный на первом проходе. Ту же защиту стоит иметь даже в номинально односторонней интеграции: односторонняя синхронизация плюс отдельная автоматизация на той стороне — это петля, которую никто не проектировал и за которую никто не отвечает.","Петля синхронизации — эхо между двумя системами, уведомляющими друг друга об изменениях: как оно начинается и чем его разорвать.",null,[11,14,17,20,23],{"slug":12,"name":13},"event-ordering","Порядок событий",{"slug":15,"name":16},"idempotency","Идемпотентность (Idempotency)",{"slug":18,"name":19},"sync-conflict-resolution","Разрешение конфликтов синхронизации",{"slug":21,"name":22},"two-way-sync","Двусторонняя синхронизация",{"slug":24,"name":25},"webhook","Вебхук (Webhook)",[27,31,34,38,41,44,47,50,53,54,57,60],{"slug":28,"category":5,"name":29,"updated_at":30},"api-deprecation","Устаревание API","2026-09-08T21:32:37+00:00",{"slug":32,"category":5,"name":33,"updated_at":30},"app-review","Проверка приложения",{"slug":35,"category":5,"name":36,"updated_at":37},"backend-for-frontend","Backend for Frontend (BFF)","2026-09-08T21:32:36+00:00",{"slug":39,"category":5,"name":40,"updated_at":30},"bulk-api","Массовый API",{"slug":42,"category":5,"name":43,"updated_at":37},"concurrency-limit","Лимит параллельных запросов",{"slug":45,"category":5,"name":46,"updated_at":30},"connector-versioning","Версионирование коннекторов",{"slug":48,"category":5,"name":49,"updated_at":30},"delete-propagation","Распространение удалений",{"slug":51,"category":5,"name":52,"updated_at":30},"effective-permissions","Действующие права",{"slug":12,"category":5,"name":13,"updated_at":37},{"slug":55,"category":5,"name":56,"updated_at":37},"field-mapping","Сопоставление полей (field mapping)",{"slug":58,"category":5,"name":59,"updated_at":37},"function-schema","Схема функции",{"slug":61,"category":5,"name":62,"updated_at":37},"grpc","gRPC"]