Как мы сократили задержки синхронизации на 40% в крупнейшей розничной сети

«Северный Ритейл» — федеральная сеть из 12 400 магазинов, 3 DC и 1.8M SKU. До SyncOps рассинхрон цен и остатков между кассами и центральным складом достигал 47 минут. После внедрения — 28 секунд.

Дашборд SyncOps с метриками синхронизации для розничной сети — lag, throughput и состояние пайплайнов в реальном времени

Исходные проблемы

47 минут рассинхрона и 200+ тикетов в месяц

Кассовые терминалы в регионах работали с данными, которые могли устареть на полтора часа. Каждый рассинхрон — это либо «цена на кассе не совпадает с чеком», либо «товара нет, но система говорит, что есть».

Сеть «Северный Ритейл» строила свою инфраструктуру данных с 2016 года. Архитектура: центральный PostgreSQL (1.2TB), 4 региональных реплики через pglogical, кэш цен в Redis на каждом DC, а остатки — в отдельной системе на MongoDB. Синхронизация между компонентами держалась на 14 самописных скриптах, запускавшихся по cron каждые 5–30 минут.

Проблема была системной: при пиковой нагрузке (вечер пятницы, распродажи) lag между центральным и региональными узлами вырастал до 47 минут. Операторы получали 200+ тикетов от магазинов ежемесячно. Команда из 6 человек проводила 70% времени на расследовании рассинхрона, а не на развитии.

Ключевые боли: отсутствие единого checkpoint, «тихие» конфликты при параллельной записи из разных DC, невозможность отследить, какое сообщение где застряло, и полное отсутствие SLA на задержку доставки данных до кассовых терминалов.

Архитектура решения

Одна декларативная топология вместо 14 скриптов

Мы заменили cron-скрипты на 7 пайплайнов SyncOps с гарантией exactly-once и автоматическим recovery. Развёртывание заняло 3 недели, миграцию — ещё 2.

Центральный хаб → 4 DC

PostgreSQL (1.2TB) как единый источник правды. Пайплайн CDC → Kafka → SyncOps-агенты в каждом DC. Lag сократился с 47 мин до 3.2 сек P99. Checkpoint каждые 500ms.

pipeline: cdc-central → kafka → dc-agents

Кэш цен: Redis geo-replication

Redis-кластер в каждом DC синхронизируется через SyncOps с conflict-resolution по vector clocks. При параллельной записи из двух DC конфликт логируется и разрешается за <2ms. Раньше — «тихая перезапись».

strategy: vector-clocks · latency: <2ms

Остатки: MongoDB → ClickHouse

Старая система остатков на MongoDB мигрирована на ClickHouse для аналитики. SyncOps-пайплайн с batch-модом (5000 msg/пакет) и идемпотентным применением. Throughput: 180K msg/s.

mode: batch · throughput: 180K msg/s

Кассовые терминалы: push-кэш

Лёгкий SyncOps-edge-агент на каждом из 12 400 терминалов. Получает delta-обновления цен и остатков по WebSocket. При потере связи — локальный WAL-журнал на 4 часа, авто-ресинхронизация при восстановлении.

edge: 12 400 nodes · wal: 4h offline

Observability и алерты

Все метрики (lag, checkpoint-age, backlog, conflict-rate) в Grafana + PagerDuty. Алерт срабатывает при lag > 5 сек. До SyncOps оператор узнавал о рассинхроне из тикета магазина через 20–40 минут.

export: prometheus · otel · grafana

Автоматический recovery

При падении DC-агента SyncOps автоматически переключает трафик на ближайший DC, а после восстановления — прогребает WAL-журнал и догоняет отставание. В течение 2024 года 3 инцидента с полным восстановлением без участия оператора.

incidents: 3 · manual intervention: 0

Результаты

Цифры через 90 дней после запуска

Измерено на проде с 12 марта по 11 июня 2024. Методология: P99 по 7 пайплайнам, 12 400 edge-узлов, 4 DC.

28сек

P99 задержка (было 47 мин)

-40%

Снижение латентности

18%

Тикетов (было 200/мес)

Потерянных событий за 90 дн

Экономический эффект: сокращение операционных затрат на 3.2M ₽/мес (уволен 1 contractor на мониторинг, 2 FTE переключены на развитие). Снижение возвратов из-за несовпадения цен — на 14%. Рост среднего чека на 2.1% за счёт актуальности данных о наличии товара на кассе.

Надёжность: 99.97% uptime за 90 дней. Три инцидента (падение DC-агента в Новосибирске, деградация сети между DC-Москва и DC-Екатеринбург, плановая миграция ClickHouse) — все отработали автоматически без участия оператора. Среднее время восстановления: 11 секунд.

Комментарий клиента

«Первый раз за 8 лет мы перестали гасить пожары»

Раньше каждый рассинхрон — это 3 часа на расследование: кто, что, где и почему. С SyncOps мы видим lag в реальном времени, а система сама догоняет отставание. Команда из 6 человек теперь занимается развитием, а не firefighting. Это редкий случай, когда внедрение инфраструктурного решения дало измеримый бизнес-эффект уже в первый месяц.

Алексей Верещагин · CTO, «Северный Ритейл» · 12 400 магазинов · 3 DC

Проект реализован командой SyncOps в составе: архитектор данных, 2 инженера по внедрению, 1 DevOps. Сопровождение по тарифу Enterprise — 99.95% SLA с финансовой компенсацией, 24/7 on-call, квартальные аудиты пайплайнов.

Хотите так же

Обсудим вашу инфраструктуру данных

Проведём бесплатный аудит текущих пайплайнов синхронизации. Покажем, где теряются секунды и деньги. Без обязательств — просто цифры и план.

Запросить аудит → Читать документацию Ответ в течение 4 рабочих часов · NDA по запросу