Sync Engine: mga pangunahing konsepto, uri, at mekanismo ng paggana

Ano ang synchronization engine?

Sync Engine — ay isang architectural layer sa pagitan ng lokal na database at malayuang API na namamahala sa daloy ng data sa parehong direksyon. Ang mga gawain nito: subaybayan ang mga pagbabago, ipadala ang mga ito sa server, tumanggap ng mga pagbabago mula sa server, at lutasin ang mga conflict. Ang user ay nagtatrabaho sa lokal na data, at ang Sync Engine ay walang putol na nag-sync nito sa server.

Ang Sync Engine ay maaaring built-in (Firebase Firestore, Couchbase Lite, Realm) o kustom — isinulat para sa partikular na lohika ng negosyo. Ang mga built-in na engine ay nag-aalok ng handa na offline-first functionality at conflict resolution. Ang mga kustom na engine ay nagbibigay ng ganap na kontrol sa format ng data, synchronization protocol, at patakaran sa conflict.

Ayon kay Sravan Kartik (2024), may-akda ng aklat na «Mobile Sync Engine Design Patterns», ang isang kustom na Sync Engine ay makatwiran para sa mga application na may kumplikadong lohika ng negosyo (pananalapi, medisina, IoT), kung saan kritikal ang mga kustom na panuntunan sa pagsasama. Para sa mga tipikal na senaryo (mga tala, chat, feed) sapat na ang built-in na Firestore o 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>
}

Inilalarawan ng interface na ito ang pinakamababang kontrata ng Sync Engine: pull (pagkuha ng mga pagbabago mula sa server), push (pagpapadala ng mga lokal na pagbabago), resolve (pangangasiwa ng mga conflict), at observe (pagmamasid sa status ng synchronization). Ang abstraksyong ito ay nagbibigay-daan sa pagbabago ng implementasyon nang hindi binabago ang Presentation layer.

Mga uri ng synchronization: buo, incremental, at push

Full sync (buong synchronization) — bawat session ay nagda-download ng buong set ng data mula sa server. Simpleng implementasyon, ngunit hindi katanggap-tanggap para sa malalaking volume: ang pag-download ng 10,000 records sa bawat pagbukas ng app ay kumokonsumo ng traffic at baterya. Ang full sync ay makatwiran para sa reference data (listahan ng bansa) na may madalang na pag-update.

Incremental sync (incremental na synchronization) — tanging ang mga record na nagbago mula noong huling synchronization ang ipinapadala. Ang server ay nag-iimbak ng timestamp ng huling pagbabago para sa bawat record o buong set. Ang client ay nagpapadala ng lastSyncTimestamp at tumatanggap lamang ng mga record na may updated_at > halagang ito. Ayon sa Instagram Engineering (2024), ang incremental sync ay nagbabawas ng dami ng ipinadalang data ng 97% kumpara sa full sync.

Push sync (synchronization na pinasimulan ng server) — ang server mismo ang nag-aabiso sa client tungkol sa pangangailangan ng synchronization sa pamamagitan ng FCM (Firebase Cloud Messaging), WebSocket, o SSE (Server-Sent Events). Hindi gumagasta ang client ng resources para sa periodic polling. Ang push sync ay ang pinakamainam na solusyon para sa real-time na mga application: chat, notification, likes. Google Firebase Firestore ay gumagamit ng WebSocket para sa real-time na synchronization na may awtomatikong fallback sa HTTP polling.

Hybrid na diskarte — kombinasyon ng mga uri: sa pagsisimula ng app full sync para sa pangunahing data, pagkatapos incremental sync para sa mga update, at para sa mga kritikal na pangyayari — push sync sa pamamagitan ng FCM. Ito ay nagbibigay ng parehong bilis at pagtitipid ng resources.

Incremental sync — paano gumagana ang mga checkpoint at delta

Checkpoint — isang halaga na iniimbak ng client sa pagitan ng mga synchronization session. Karaniwan ito ay ang updated_at ng huling matagumpay na nai-sync na record. Sa susunod na synchronization, ipinapadala ng client ang checkpoint sa server, at ibinabalik ng server ang lahat ng record na may updated_at pagkatapos ng checkpoint. Cursor-based pagination — isang advanced na bersyon kung saan ibinabalik ng server ang isang cursor (pointer sa susunod na page) kasama ng data.

Delta synchronization — kinakalkula ng server ang pagkakaiba sa pagitan ng kasalukuyang estado ng data at ng snapshot na nakita ng client. Sa halip na ipadala ang lahat ng record, tanging ang mga operasyon (insert, update, delete) ang ipinapadala. Ito ay lalong epektibo para sa malalaking set ng data kung saan ilang record lamang ang nagbago. Google Drive API (2025) ay gumagamit ng changes.list na may pageToken para sa delta synchronization ng mga file.

Estratehiya ng «naantalang delta» — sa mobile client, ang mga pagbabago ay hindi agad ipinapadala, kundi naka-buffer sa Offline Queue. Kapag naabot ang threshold (10 operasyon o 30 segundo), isang delta package ang nabubuo at ipinapadala sa server. Ayon sa Dropbox Mobile Engineering (2024), ang pag-batch ng delta ay nagbawas ng bilang ng HTTP requests ng 65% at nagpababa ng konsumo ng baterya ng 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
    )

Ang SyncCheckpoint ay nag-iimbak ng parehong timestamp at pagination cursor para sa mahabang listahan. Dalawang-parameter na checkpoint ay ginagarantiyang walang record na makaligtaan o madoble sa panahon ng synchronization ng malalaking set ng data.

Push sync — agarang synchronization sa pamamagitan ng WebSocket at FCM

WebSocket — isang permanenteng two-way na koneksyon sa pagitan ng client at server. Ang server ay nagpapadala ng mga update kaagad pagkatapos magbago ang data. Ang WebSocket ay pinakamainam para sa real-time na mga application: chat, streaming, collaborative na trabaho. Disbentaha: konsumo ng baterya at traffic para sa pagpapanatili ng koneksyon (heartbeat). OkHttp WebSocket sa Android at URLSessionWebSocketTask sa iOS — mga built-in na implementasyon.

Firebase Cloud Messaging (FCM) — push notification na ipinapadala ng server hindi para ipakita sa user, kundi para i-trigger ang synchronization. Sa pagtanggap ng silent push (data message), nagigising ang app at pinapatakbo ang Sync Engine. Ang FCM ay hindi nangangailangan ng permanenteng koneksyon at mas matipid kaysa WebSocket para sa madalang na notification.

SSE (Server-Sent Events) — isang one-way na channel kung saan ang server ay nagpapadala ng mga event sa client. Mas simple ipatupad kaysa WebSocket, ngunit hindi sumusuporta sa two-way na komunikasyon. EventSource API (JavaScript) at OkHttp SSE (Android) — mga popular na library. Ang SSE ay angkop para sa mga notification tungkol sa bagong data kapag hindi kailangan ng client na magpadala ng data pabalik sa parehong channel.

Ayon sa WhatsApp Engineering (2024), ang kanilang Sync Engine ay gumagamit ng kombinasyon ng WebSocket para sa aktibong session at FCM para gisingin ang app sa background: ang WebSocket ay nadidiskonekta pagkatapos ng 5 minuto ng kawalan ng aktibidad, at ang mga susunod na update ay inihatid sa pamamagitan ng silent push.

Snapshot sync at pag-version ng data

Snapshot-based sync — ang server ay pana-panahong gumagawa ng kumpletong snapshot ng data at nagtatalaga ng bersyon dito. Iniimbak ng client ang kasalukuyang numero ng bersyon. Kung luma na — nagda-download ng bagong snapshot. Ito ay isang simple at maaasahang estratehiya, ngunit hindi epektibo para sa madalas na pagbabago — sa bawat oras ay nagda-download ng kumpletong set ng data.

Pag-version sa antas ng record — bawat record ay may field na version. Sa panahon ng synchronization, ipinapadala ng client ang mga bersyon ng lahat ng record, at ang server ay nagbabalik lamang ng mga record na nagbago ang bersyon. Ito ay mas epektibo kaysa snapshot sync, ngunit nangangailangan ng pag-iimbak ng mga bersyon sa client. Vector Clocks — isang advanced na teknik para sa distributed system, kung saan ang bawat node ay nagtatalaga ng sarili nitong bersyon at ang mga conflict ay nareresolba ayon sa partial order.

Snapshot na may incremental diff — hybrid na diskarte: bihirang kumpletong snapshot (isang beses sa isang araw) + incremental sync sa pagitan ng mga ito. Pagkatapos ng mahabang pagkawala, nagda-download ang client ng snapshot, at sa madalas na synchronization — delta lamang. Diskarteng tulad ng Git — bawat commit ng data ay may hash, at alam ng client kung saang commit magsisimula. Ito ay naipatupad sa Couchbase Lite Sync Gateway (2024) at ito ay pamantayan ng pagiging maaasahan.

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)
    }

Patakaran sa pagresolba ng bersyon: kung magkatugma ang mga bersyon — walang pagbabago. Kung mas bago ang lokal na bersyon — panalo ang lokal. Kung mas bago ang bersyon ng server — panalo ang server. Sa pantay na bersyon ngunit magkaibang data lamang — tinatawag ang conflict resolver. Last Write Wins na may version flag — ang pinakasimple ngunit maaasahang estratehiya.

Paano bumuo ng Sync Engine para sa mobile application

Hakbang 1: Tukuyin ang modelo ng data — aling mga entity ang naka-sync, gaano kadalas nagbabago, ano ang volume. Para sa bawat entity itakda ang estratehiya (incremental / full / push) at pinapayagang oras ng pagkaantala ng synchronization.

Hakbang 2: Pumili ng protocol — REST na may checkpoint, GraphQL na may Subscriptions, o gRPC na may bidirectional stream. GraphQL Subscriptions — popular na pagpipilian para sa modernong apps: isang protocol para sa parehong pull at push. Ang Apollo Client (2025) ay sumusuporta sa offline sync sa pamamagitan ng cache sa device.

Hakbang 3: Ipatupad ang Offline Queue — lokal na imbakan ng mga pagbabago na may idempotency keys (tingnan ang artikulong «Offline Queue»). Ang pila ay pundasyon ng maaasahang Sync Engine: kung wala ito, hindi ginagarantiya ng synchronization ang paghahatid ng mga pagbabago.

Hakbang 4: Pumili ng conflict resolver — LWW para sa simpleng kaso, CRDT para sa collaborative editing, Custom merge para sa lohika ng negosyo. Patakaran: ang resolver ay dapat idempotent — ang paulit-ulit na paglalapat ng parehong operasyon ay dapat magbigay ng parehong resulta.

Hakbang 5: Pagsubaybay at mga metriko — i-log ang bawat synchronization: bilang ng mga record, oras ng pag-execute, bilang ng conflict, error. Firebase Crashlytics o Sentry (2025) ay nagbibigay-daan sa pagsubaybay ng mga error sa synchronization sa real-time.

Ayon sa Realm Team (2024), ang isang tipikal na Sync Engine para sa mobile app ay nagpoproseso ng 100–500 synchronization bawat araw bawat device, na nagpapadala ng average na 50–200 KB ng data bawat session. Pag-optimize ng protocol — compression ng Protobuf sa halip na JSON — ay nagbabawas ng dami ng ipinadalang data ng karagdagang 40–60%.