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 позивање.

Хибридни приступ — комбинација типова: при покретању апликације full sync за основне податке, затим incremental 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 са инкременталним diff-ом — хибридни приступ: редак комплетан снимак (једном дневно) + инкрементална синхронизација између њих. После дужег одсуства клијент учитава снимак, а при честим синхронизацијама — само делте. Приступ сличан 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) подржава offline синхронизацију путем кеша на уређају.

Корак 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%.