Sync Engine: ключевые понятия, типы и механизмы работы

Что такое движок синхронизации?

Sync Engine — это архитектурный слой между локальной базой данных и удалённым API, который управляет потоком данных в обоих направлениях. Его задачи: отслеживать изменения, отправлять их на сервер, получать изменения с сервера и разрешать конфликты. Пользователь взаимодействует с локальными данными, а Sync Engine бесшовно синхронизирует их с сервером.

Sync Engine бывает встроенным (Firebase Firestore, Couchbase Lite, Realm) и кастомным — написанным под конкретную бизнес-логику. Встроенные движки предлагают готовый функционал offline-first и conflict resolution. Кастомные дают полный контроль над форматом данных, протоколом синхронизации и политикой конфликтов.

По данным Сравана Картик (2024), автор книги «Mobile Sync Engine Design Patterns», кастомный Sync Engine оправдан для приложений со сложной бизнес-логикой (финансы, медицина, IoT), где кастомные правила слияния критичны. Для типовых сценариев (заметки, чаты, ленты) достаточно встроенного Firestore или Realm.

interface SyncEngine {
    suspend fun pull(lastSyncTimestamp: Long): SyncResult
    suspend fun push(operations: List<QueuedOperation>): PushResult
    suspend fun resolve(conflicts: List<Conflict>): ResolutionResult
    fun observeSyncState(): Flow<SyncState>
}

Этот интерфейс описывает минимальный контракт Sync Engine: pull (загрузка изменений с сервера), push (отправка локальных изменений), resolve (обработка конфликтов) и observe (наблюдение за состоянием синхронизации). Такая абстракция позволяет менять реализацию без изменения слоя Presentation.

Типы синхронизации: полная, инкрементальная и push

Full sync (полная синхронизация) — при каждом сеансе загружается весь набор данных с сервера. Простая реализация, но неприемлема для больших объёмов: загрузка 10 000 записей при каждом открытии приложения расходует трафик и батарею. Full sync оправдан для справочных данных (список стран) с редкими обновлениями.

Incremental sync (инкрементальная) — передаются только записи, изменившиеся с момента последней синхронизации. Сервер хранит временную метку последнего изменения для каждой записи или всего набора. Клиент передаёт lastSyncTimestamp и получает только записи с updated_at > это значение. По данным Instagram Engineering (2024), incremental sync сокращает объём передаваемых данных на 97% по сравнению с full sync.

Push sync (сервер-инициированная) — сервер сам уведомляет клиента о необходимости синхронизации через FCM (Firebase Cloud Messaging), WebSocket или SSE (Server-Sent Events). Клиент не тратит ресурсы на периодический поллинг. Push sync — оптимальный вариант для приложений реального времени: чаты, уведомления, лайки. Google Firebase Firestore использует WebSocket для real-time sync с автоматическим fallback на HTTP polling.

Гибридный подход — комбинация типов: при старте приложения full sync для базовых данных, затем incremental sync для обновлений, а для критических событий — push sync через FCM. Это даёт и скорость, и экономию ресурсов.

Incremental sync — как работают чекпоинты и дельты

Чекпоинт — значение, которое клиент хранит между сессиями синхронизации. Обычно это updated_at последней успешно синхронизированной записи. При следующей синхронизации клиент передаёт чекпоинт серверу, и тот возвращает все записи с updated_at позже чекпоинта. Cursor-based pagination — продвинутая версия, где сервер возвращает курсор (указатель на следующую страницу) вместе с данными.

Дельта-синхронизация — сервер вычисляет diff между текущим состоянием данных и слепком, который видел клиент. Вместо отправки всех записей передаются только операции (insert, update, delete). Это особенно эффективно для больших массивов данных, где изменилось лишь несколько записей. Google Drive API (2025) использует changes.list с pageToken для дельта-синхронизации файлов.

Стратегия «отложенных дельт» — на мобильном клиенте изменения не отправляются немедленно, а буферизируются в Offline Queue. При достижении порога (10 операций или 30 секунд) формируется дельта-пакет и отправляется на сервер. По данным Dropbox Mobile Engineering (2024), батчинг дельт сократил количество HTTP-запросов на 65% и снизил потребление батареи на 12%.

data class SyncCheckpoint(
    val lastUpdated: Long,
    val pageToken: String?,
    val version: Int
)

suspend fun syncIncremental(checkpoint: SyncCheckpoint): SyncResult =
    api.pullChanges(
        since = checkpoint.lastUpdated,
        token = checkpoint.pageToken
    )

SyncCheckpoint хранит как временную метку, так и курсор пагинации для длинных списков. Двухпараметрический чекпоинт гарантирует, что ни одна запись не будет пропущена или продублирована при синхронизации больших наборов данных.

Push sync — мгновенная синхронизация через WebSocket и FCM

WebSocket — постоянное двунаправленное соединение между клиентом и сервером. Сервер отправляет обновления сразу при изменении данных. WebSocket оптимален для приложений реального времени: чаты, стриминг, коллаборативная работа. Минус: расход батареи и трафика на поддержание соединения (heartbeat). OkHttp WebSocket на Android и URLSessionWebSocketTask на iOS — встроенные реализации.

Firebase Cloud Messaging (FCM) — push-уведомления, которые сервер отправляет не для показа пользователю, а для триггера синхронизации. При получении silent push (data message) приложение просыпается и запускает Sync Engine. FCM не требует постоянного соединения и экономичнее WebSocket для редких уведомлений.

SSE (Server-Sent Events) — односторонний канал, по которому сервер шлёт события клиенту. Проще WebSocket в реализации, но не поддерживает двустороннюю связь. ЕventSource API (JavaScript) и OkHttp SSE (Android) — популярные библиотеки. SSE подходит для уведомлений о новых данных, когда клиенту не нужно отправлять данные обратно по тому же каналу.

По данным WhatsApp Engineering (2024), их Sync Engine использует комбинацию WebSocket для активной сессии и FCM для пробуждения приложения в фоне: WebSocket отключается после 5 минут неактивности, и последующие обновления доставляются через silent push.

Snapshot sync и версионирование данных

Snapshot-based sync — сервер периодически создаёт полный слепок данных (snapshot) и присваивает ему версию. Клиент хранит номер текущей версии. Если она устарела — загружает новый слепок. Это простая и надёжная стратегия, но неэффективная для частых изменений — каждый раз загружается полный набор данных.

Версионирование на уровне записи — каждая запись имеет поле version. При синхронизации клиент отправляет версии всех записей, а сервер возвращает только те, чья версия изменилась. Это эффективнее snapshot sync, но требует хранения версий на клиенте. Vector Clocks — продвинутая техника для распределённых систем, где каждая нода присваивает свою версию и конфликты разрешаются по partial order.

Snapshot с инкрементальным diff — гибридный подход: редкий полный snapshot (раз в день) + incremental sync между ними. При старте после долгого отсутствия клиент загружает snapshot, а при частых синхронизациях — только дельты. Git-подобный подход — каждый коммит данных имеет хеш, и клиент знает, от какого коммита отталкиваться. Это реализовано в Couchbase Lite Sync Gateway (2024) и является эталоном надёжности.

data class VersionedEntryT(
    val id: String,
    val data: T,
    val version: Long,
    val deleted: Boolean
)

fun SyncEngine.resolveVersion(local: VersionedEntry*, remote: VersionedEntry*): VersionedEntry* =
    when {
        local.version > remote.version -> local
        remote.version > local.version -> remote
        else -> resolveConflict(local, remote)
    }

Правило разрешения версий: если версии совпадают — изменений нет. Если локальная версия новее — побеждает локальная. Если серверная новее — побеждает серверная. Только при равных версиях, но разных данных — вызывается conflict resolver. Last Write Wins с version-флагом — простейшая, но надёжная стратегия.

Как построить Sync Engine для мобильного приложения

Шаг 1: Определить модель данных — какие сущности синхронизируются, как часто меняются, какой объём. Для каждой сущности зафиксировать стратегию (incremental / full / push) и допустимое время задержки синхронизации.

Шаг 2: Выбрать протокол — REST с чекпоинтами, GraphQL с Subscriptions или gRPC с bidirectional stream. GraphQL Subscriptions — популярный выбор для современных приложений: один протокол и на pull, и на push. Apollo Client (2025) поддерживает offline sync через кэш на устройстве.

Шаг 3: Реализовать Offline Queue — локальное хранилище изменений с idempotency keys (см. статью «Offline Queue»). Очередь — фундамент надёжного Sync Engine: без неё синхронизация не гарантирует доставку изменений.

Шаг 4: Выбрать conflict resolver — LWW для простых случаев, CRDT для совместного редактирования, Custom merge для бизнес-логики. Правило: resolver должен быть идемпотентным — повторное применение той же операции должно давать тот же результат.

Шаг 5: Мониторинг и метрики — логировать каждую синхронизацию: количество записей, время выполнения, количество конфликтов, ошибки. Firebase Crashlytics или Sentry (2025) позволяют отслеживать ошибки синхронизации в реальном времени.

По данным Realm Team (2024), типовой Sync Engine для мобильного приложения обрабатывает 100–500 синхронизаций в день на устройство, передавая в среднем 50–200 КБ данных за сессию. Оптимизация протокола — сжатие Protobuf вместо JSON — сокращает объём передаваемых данных ещё на 40–60%.