Sync Engine: konsep utama, jenis, dan mekanisme kerja

Apa itu mesin sinkronisasi?

Sync Engine — adalah lapisan arsitektur antara basis data lokal dan API jarak jauh yang mengelola aliran data di kedua arah. Tugasnya: melacak perubahan, mengirimkannya ke server, menerima perubahan dari server, dan menyelesaikan konflik. Pengguna bekerja dengan data lokal, dan Sync Engine menyinkronkannya dengan server secara mulus.

Sync Engine bisa bawaan (Firebase Firestore, Couchbase Lite, Realm) atau kustom — ditulis untuk logika bisnis tertentu. Mesin bawaan menawarkan fungsionalitas offline-first dan resolusi konflik yang siap pakai. Mesin kustom memberikan kontrol penuh atas format data, protokol sinkronisasi, dan kebijakan konflik.

Menurut Sravan Kartik (2024), penulis buku «Mobile Sync Engine Design Patterns», Sync Engine kustom dibenarkan untuk aplikasi dengan logika bisnis kompleks (keuangan, medis, IoT), di mana aturan penggabungan kustom sangat penting. Untuk skenario tipikal (catatan, obrolan, feed), Firestore atau Realm bawaan sudah cukup.

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

Antarmuka ini menjelaskan kontrak minimal Sync Engine: pull (mengambil perubahan dari server), push (mengirim perubahan lokal), resolve (menangani konflik), dan observe (memantau status sinkronisasi). Abstraksi ini memungkinkan perubahan implementasi tanpa mengubah lapisan Presentation.

Jenis sinkronisasi: penuh, inkremental, dan push

Full sync (sinkronisasi penuh) — setiap sesi mengunduh seluruh kumpulan data dari server. Implementasi sederhana, tetapi tidak dapat diterima untuk volume besar: mengunduh 10.000 catatan setiap kali membuka aplikasi menghabiskan traffic dan baterai. Full sync dibenarkan untuk data referensi (daftar negara) dengan pembaruan jarang.

Incremental sync (sinkronisasi inkremental) — hanya catatan yang berubah sejak sinkronisasi terakhir yang dikirimkan. Server menyimpan stempel waktu perubahan terakhir untuk setiap catatan atau seluruh kumpulan. Klien mengirimkan lastSyncTimestamp dan hanya menerima catatan dengan updated_at > nilai ini. Menurut Instagram Engineering (2024), incremental sync mengurangi volume data yang dikirimkan sebesar 97% dibandingkan full sync.

Push sync (sinkronisasi yang diprakarsai server) — server sendiri memberitahu klien tentang perlunya sinkronisasi melalui FCM (Firebase Cloud Messaging), WebSocket, atau SSE (Server-Sent Events). Klien tidak menghabiskan sumber daya untuk polling berkala. Push sync adalah solusi optimal untuk aplikasi waktu nyata: obrolan, notifikasi, suka. Google Firebase Firestore menggunakan WebSocket untuk sinkronisasi waktu nyata dengan fallback otomatis ke HTTP polling.

Pendekatan hibrida — kombinasi jenis: saat memulai aplikasi full sync untuk data dasar, kemudian incremental sync untuk pembaruan, dan untuk peristiwa kritis — push sync melalui FCM. Ini memberikan kecepatan dan penghematan sumber daya.

Incremental sync — cara kerja checkpoint dan delta

Checkpoint — nilai yang disimpan klien di antara sesi sinkronisasi. Biasanya ini adalah updated_at dari catatan terakhir yang berhasil disinkronkan. Pada sinkronisasi berikutnya, klien mengirimkan checkpoint ke server, dan server mengembalikan semua catatan dengan updated_at lebih baru dari checkpoint. Cursor-based pagination — versi lanjutan di mana server mengembalikan kursor (penunjuk ke halaman berikutnya) bersama dengan data.

Sinkronisasi delta — server menghitung perbedaan antara status data saat ini dan snapshot yang dilihat klien. Alih-alih mengirim semua catatan, hanya operasi (insert, update, delete) yang dikirimkan. Ini sangat efisien untuk kumpulan data besar di mana hanya beberapa catatan yang berubah. Google Drive API (2025) menggunakan changes.list dengan pageToken untuk sinkronisasi delta file.

Strategi «delta tertunda» — pada klien seluler, perubahan tidak dikirim segera, tetapi disangga di Offline Queue. Setelah mencapai ambang batas (10 operasi atau 30 detik), paket delta dibentuk dan dikirim ke server. Menurut Dropbox Mobile Engineering (2024), pengelompokan delta mengurangi jumlah permintaan HTTP sebesar 65% dan menurunkan konsumsi baterai sebesar 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 menyimpan baik stempel waktu maupun kursor paginasi untuk daftar panjang. Checkpoint dua parameter menjamin bahwa tidak ada catatan yang terlewat atau terduplikasi selama sinkronisasi kumpulan data besar.

Push sync — sinkronisasi instan melalui WebSocket dan FCM

WebSocket — koneksi permanen dua arah antara klien dan server. Server mengirim pembaruan segera setelah data berubah. WebSocket optimal untuk aplikasi waktu nyata: obrolan, streaming, kerja kolaboratif. Kekurangan: konsumsi baterai dan traffic untuk mempertahankan koneksi (heartbeat). OkHttp WebSocket di Android dan URLSessionWebSocketTask di iOS — implementasi bawaan.

Firebase Cloud Messaging (FCM) — notifikasi push yang dikirim server bukan untuk ditampilkan kepada pengguna, tetapi untuk memicu sinkronisasi. Setelah menerima silent push (data message), aplikasi terbangun dan menjalankan Sync Engine. FCM tidak memerlukan koneksi permanen dan lebih hemat daripada WebSocket untuk notifikasi yang jarang.

SSE (Server-Sent Events) — saluran satu arah di mana server mengirim peristiwa ke klien. Lebih sederhana diimplementasikan daripada WebSocket, tetapi tidak mendukung komunikasi dua arah. EventSource API (JavaScript) dan OkHttp SSE (Android) — pustaka populer. SSE cocok untuk notifikasi tentang data baru ketika klien tidak perlu mengirim data kembali melalui saluran yang sama.

Menurut WhatsApp Engineering (2024), Sync Engine mereka menggunakan kombinasi WebSocket untuk sesi aktif dan FCM untuk membangunkan aplikasi di latar belakang: WebSocket terputus setelah 5 menit tidak aktif, dan pembaruan selanjutnya dikirimkan melalui silent push.

Snapshot sync dan versi data

Snapshot-based sync — server secara periodik membuat snapshot lengkap data dan memberinya versi. Klien menyimpan nomor versi saat ini. Jika sudah usang — mengunduh snapshot baru. Ini adalah strategi sederhana dan andal, tetapi tidak efisien untuk perubahan yang sering — setiap kali kumpulan data lengkap diunduh.

Versi di tingkat catatan — setiap catatan memiliki bidang version. Saat sinkronisasi, klien mengirim versi semua catatan, dan server hanya mengembalikan catatan yang versinya berubah. Ini lebih efisien daripada snapshot sync, tetapi memerlukan penyimpanan versi di klien. Vector Clocks — teknik lanjutan untuk sistem terdistribusi, di mana setiap node memberikan versinya sendiri dan konflik diselesaikan berdasarkan urutan parsial.

Snapshot dengan diff inkremental — pendekatan hibrida: snapshot lengkap jarang (sekali sehari) + sinkronisasi inkremental di antaranya. Setelah ketidakhadiran lama, klien mengunduh snapshot, dan pada sinkronisasi sering — hanya delta. Pendekatan mirip Git — setiap komit data memiliki hash, dan klien tahu dari komit mana harus memulai. Ini diimplementasikan di Couchbase Lite Sync Gateway (2024) dan merupakan standar keandalan.

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

Aturan resolusi versi: jika versi cocok — tidak ada perubahan. Jika versi lokal lebih baru — versi lokal menang. Jika versi server lebih baru — server menang. Hanya jika versi sama tetapi data berbeda — conflict resolver dipanggil. Last Write Wins dengan flag version — strategi paling sederhana namun andal.

Cara membangun Sync Engine untuk aplikasi seluler

Langkah 1: Menentukan model data — entitas mana yang disinkronkan, seberapa sering berubah, berapa volumenya. Untuk setiap entitas tetapkan strategi (incremental / full / push) dan latensi sinkronisasi yang diizinkan.

Langkah 2: Memilih protokol — REST dengan checkpoint, GraphQL dengan Subscriptions, atau gRPC dengan aliran dua arah. GraphQL Subscriptions — pilihan populer untuk aplikasi modern: satu protokol untuk pull dan push. Apollo Client (2025) mendukung sinkronisasi offline melalui cache di perangkat.

Langkah 3: Menerapkan Offline Queue — penyimpanan lokal perubahan dengan kunci idempotensi (lihat artikel «Offline Queue»). Antrean adalah fondasi Sync Engine yang andal: tanpanya, sinkronisasi tidak menjamin pengiriman perubahan.

Langkah 4: Memilih conflict resolver — LWW untuk kasus sederhana, CRDT untuk pengeditan bersama, Custom merge untuk logika bisnis. Aturan: resolver harus idempoten — penerapan berulang dari operasi yang sama harus memberikan hasil yang sama.

Langkah 5: Pemantauan dan metrik — catat setiap sinkronisasi: jumlah catatan, waktu eksekusi, jumlah konflik, kesalahan. Firebase Crashlytics atau Sentry (2025) memungkinkan pelacakan kesalahan sinkronisasi secara real-time.

Menurut Realm Team (2024), Sync Engine tipikal untuk aplikasi seluler memproses 100–500 sinkronisasi per hari per perangkat, mentransmisikan rata-rata 50–200 KB data per sesi. Optimasi protokol — kompresi Protobuf daripada JSON — mengurangi volume data yang dikirimkan sebesar 40–60%.