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

Какво е двигател за синхронизация?

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

Sync Engine може да бъде вграден (Firebase Firestore, Couchbase Lite, Realm) или персонализиран — написан за конкретна бизнес логика. Вградените двигатели предлагат готова функционалност offline-first и разрешаване на конфликти. Персонализираните дават пълен контрол над формата на данните, протокола за синхронизация и политиката за конфликти.

Според Sravan Kartik (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 (наблюдение на състоянието на синхронизация). Тази абстракция позволява промяна на имплементацията без модифициране на слоя за представяне.

Видове синхронизация: пълна, инкрементална и push

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

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

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

Хибриден подход — комбинация от видове: при стартиране на приложението full sync за основни данни, след това инкрементална синхронизация за актуализации, а за критични събития — push sync чрез FCM. Това осигурява както скорост, така и спестяване на ресурси.

Incremental sync — как работят контролните точки и делтите

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

Делта синхронизация — сървърът изчислява разликата между текущото състояние на данните и моментния снимка, който клиентът е видял. Вместо изпращане на всички записи, се прехвърлят само операциите (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, но не поддържа двупосочна комуникация. EventSource 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 — усъвършенствана техника за разпределени системи, където всеки възел присвоява своя версия и конфликтите се разрешават по частичен ред.

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 с двупосочен поток. GraphQL Subscriptions — популярен избор за модерни приложения: един протокол и за pull, и за push. Apollo Client (2025) поддържа офлайн синхронизация чрез кеш на устройството.

Стъпка 3: Имплементиране на Offline Queue — локално хранилище за промени с idempotency ключове (вижте статията «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 KB данни на сесия. Оптимизация на протокола — компресия Protobuf вместо JSON — намалява обема на прехвърлените данни с още 40–60%.