Sync Engine: əsas anlayışlar, növlər və iş mexanizmləri

Sinxronizasiya mühərriki nədir?

Sync Engine — lokal verilənlər bazası ilə uzaq API arasında memarlıq təbəqəsidir və məlumat axınını hər iki istiqamətdə idarə edir. Onun vəzifələri: dəyişiklikləri izləmək, onları serverə göndərmək, serverdən dəyişiklikləri qəbul etmək və konfliktləri həll etmək. İstifadəçi lokal məlumatlarla işləyir, Sync Engine isə onları serverlə problemsiz sinxronizasiya edir.

Sync Engine daxili (Firebase Firestore, Couchbase Lite, Realm) və xüsusi — konkret biznes məntiqi üçün yazılmış ola bilər. Daxili mühərriklər hazır offline-first funksionallığı və konflikt həlli təklif edir. Xüsusi mühərriklər məlumat formatı, sinxronizasiya protokolu və konflikt siyasəti üzərində tam nəzarət verir.

Sravan Kartik (2024), «Mobile Sync Engine Design Patterns» kitabının müəllifinə görə, xüsusi Sync Engine mürəkkəb biznes məntiqi olan tətbiqlər (maliyyə, tibb, IoT) üçün əsaslandırılmışdır, burada xüsusi birləşdirmə qaydaları kritikdir. Tipik ssenarilər (qeydlər, söhbətlər, lentlər) üçün daxili Firestore və ya Realm kifayətdir.

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

Bu interfeys Sync Engine üçün minimal müqaviləni təsvir edir: pull (serverdən dəyişiklikləri yükləmə), push (lokal dəyişiklikləri göndərmə), resolve (konfliktlərin idarə edilməsi) və observe (sinxronizasiya vəziyyətinin müşahidəsi). Bu abstraksiya Presentation qatını dəyişmədən implementasiyanı dəyişməyə imkan verir.

Sinxronizasiya növləri: tam, artımlı və push

Full sync (tam sinxronizasiya) — hər seansda serverdən bütün məlumat dəsti yüklənir. Sadə implementasiya, lakin böyük həcmlər üçün qəbuledilməzdir: tətbiqin hər açılışında 10 000 qeydin yüklənməsi trafik və batareya sərf edir. Full sync nadir yeniləmələri olan istinad məlumatları (ölkə siyahısı) üçün əsaslandırılmışdır.

Incremental sync (artımlı sinxronizasiya) — son sinxronizasiyadan bəri dəyişmiş qeydlər ötürülür. Server hər qeyd və ya bütün dəst üçün son dəyişmə vaxtını saxlayır. Müştəri lastSyncTimestamp göndərir və updated_at > bu dəyər olan qeydləri alır. Instagram Engineering (2024) məlumatlarına görə, incremental sync məlumat həcmini full sync ilə müqayisədə 97% azaldır.

Push sync (server tərəfindən başladılan sinxronizasiya) — server FCM (Firebase Cloud Messaging), WebSocket və ya SSE (Server-Sent Events) vasitəsilə müştərini sinxronizasiya ehtiyacı barədə özü xəbərdar edir. Müştəri dövri pollinqə resurs sərf etmir. Push sync real vaxt tətbiqləri üçün optimal variantdır: söhbətlər, bildirişlər, bəyənmələr. Google Firebase Firestore real vaxt sinxronizasiyası üçün WebSocket-dən avtomatik HTTP polling fallback ilə istifadə edir.

Hibrid yanaşma — növlərin kombinasiyası: tətbiqin başlanğıcında əsas məlumatlar üçün full sync, sonra yeniləmələr üçün incremental sync, kritik hadisələr üçün isə FCM vasitəsilə push sync. Bu həm sürət, həm də resurs qənaəti verir.

Incremental sync — yoxlama nöqtələri və deltalar necə işləyir

Yoxlama nöqtəsi — müştərinin sinxronizasiya sessiyaları arasında saxladığı dəyər. Adətən bu, son uğurla sinxronizasiya edilmiş qeydin updated_at sahəsidir. Növbəti sinxronizasiyada müştəri yoxlama nöqtəsini serverə göndərir və server yoxlama nöqtəsindən sonrakı updated_at olan bütün qeydləri qaytarır. Cursor-based pagination — serverin məlumatlarla birlikdə kursoru (növbəti səhifənin göstəricisi) qaytardığı qabaqcıl versiya.

Delta sinxronizasiya — server cari məlumat vəziyyəti ilə müştərinin gördüyü şəkil arasında fərqi hesablayır. Bütün qeydləri göndərmək əvəzinə yalnız əməliyyatlar (insert, update, delete) ötürülür. Bu, yalnız bir neçə qeydin dəyişdiyi böyük məlumat dəstləri üçün xüsusilə effektivdir. Google Drive API (2025) faylların delta sinxronizasiyası üçün pageToken ilə changes.list istifadə edir.

Gecikmiş deltalar strategiyası — mobil müştəridə dəyişikliklər dərhal göndərilmir, Offline Queue-da buferlənir. Həddə çatdıqda (10 əməliyyat və ya 30 saniyə) delta paketi formalaşdırılır və serverə göndərilir. Dropbox Mobile Engineering (2024) məlumatlarına görə, deltaların toplanması HTTP sorğularının sayını 65% azaldıb və batareya istehlakını 12% aşağı salıb.

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 həm vaxt damğasını, həm də uzun siyahılar üçün paginasiya kursorunu saxlayır. İkiparametrli yoxlama nöqtəsi böyük məlumat dəstlərinin sinxronizasiyası zamanı heç bir qeydin atlanmamasını və ya təkrarlanmamasını təmin edir.

Push sync — WebSocket və FCM vasitəsilə ani sinxronizasiya

WebSocket — müştəri ilə server arasında daimi ikitərəfli əlaqə. Server məlumat dəyişən kimi dərhal yeniləmələri göndərir. WebSocket real vaxt tətbiqləri üçün optimaldır: söhbətlər, streaming, əməkdaşlıq işi. Minus: əlaqəni saxlamaq üçün batareya və trafik sərfi (heartbeat). Android-də OkHttp WebSocket və iOS-da URLSessionWebSocketTask daxili implementasiyalardır.

Firebase Cloud Messaging (FCM) — serverin istifadəçiyə göstərmək üçün deyil, sinxronizasiyanı tetikləmək üçün göndərdiyi push bildirişləridir. Silent push (data message) qəbul edildikdə tətbiq oyanır və Sync Engine-i işə salır. FCM daimi əlaqə tələb etmir və nadir bildirişlər üçün WebSocket-dən daha qənaətcildir.

SSE (Server-Sent Events) — serverin müştəriyə hadisələr göndərdiyi birtərəfli kanal. WebSocket-dən daha sadədir, lakin ikitərəfli əlaqəni dəstəkləmir. EventSource API (JavaScript) və OkHttp SSE (Android) məşhur kitabxanalardır. SSE müştərinin eyni kanal vasitəsilə geri məlumat göndərməsinə ehtiyac olmadıqda yeni məlumatlar barədə bildirişlər üçün uyğundur.

WhatsApp Engineering (2024) məlumatlarına görə, onların Sync Engine aktiv sessiya üçün WebSocket və tətbiqi fona oyatmaq üçün FCM kombinasiyasından istifadə edir: WebSocket 5 dəqiqəlik hərəkətsizlikdən sonra sönür və sonrakı yeniləmələr silent push vasitəsilə çatdırılır.

Snapshot sync və məlumatların versiyalaşdırılması

Snapshot-based sync — server dövri olaraq tam məlumat şəklini (snapshot) yaradır və ona versiya təyin edir. Müştəri cari versiya nömrəsini saxlayır. Əgər versiya köhnəlibsə — yeni şəkli yükləyir. Bu sadə və etibarlı strategiyadır, lakin tez-tez dəyişikliklər üçün səmərəsizdir — hər dəfə tam məlumat dəsti yüklənir.

Qeyd səviyyəsində versiyalaşdırma — hər qeydin version sahəsi var. Sinxronizasiya zamanı müştəri bütün qeydlərin versiyalarını göndərir, server isə yalnız versiyası dəyişmiş qeydləri qaytarır. Bu, snapshot sync-dən daha səmərəlidir, lakin müştəridə versiyaların saxlanmasını tələb edir. Vector Clocks — paylanmış sistemlər üçün qabaqcıl texnika, burada hər node öz versiyasını təyin edir və konfliktlər qismən sıra ilə həll olunur.

Artımlı diff ilə snapshot — hibrid yanaşma: nadir tam snapshot (gündə bir dəfə) + onların arasında incremental sync. Uzun müddət olmadıqdan sonra müştəri snapshot yükləyir, tez-tez sinxronizasiyalarda isə yalnız deltalar. Git-ə bənzər yanaşma — hər məlumat commit-inin heşi var və müştəri hansı commit-ə əsaslanacağını bilir. Bu, Couchbase Lite Sync Gateway-də (2024) tətbiq edilmişdir və etibarlılıq standartıdır.

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

Versiyaların həlli qaydası: versiyalar uyğun gəlirsə — dəyişiklik yoxdur. Lokal versiya daha yenidirsə — lokal qalib gəlir. Server versiyası daha yenidirsə — server qalib gəlir. Yalnız bərabər versiyalar, lakin fərqli məlumatlar olduqda conflict resolver çağırılır. Last Write Wins version flag ilə — ən sadə, lakin etibarlı strategiya.

Mobil tətbiq üçün Sync Engine necə qurulur

Addım 1: Məlumat modelini müəyyənləşdirin — hansı varlıqlar sinxronizasiya olunur, nə qədər tez-tez dəyişir, həcmi nə qədərdir. Hər varlıq üçün strategiya (incremental / full / push) və yol verilən sinxronizasiya gecikməsi müəyyən edilir.

Addım 2: Protokolu seçin — REST yoxlama nöqtələri ilə, GraphQL Subscriptions və ya gRPC bidirectional stream ilə. GraphQL Subscriptions — müasir tətbiqlər üçün məşhur seçimdir: həm pull, həm də push üçün bir protokol. Apollo Client (2025) cihazda keş vasitəsilə offline sync-i dəstəkləyir.

Addım 3: Offline Queue-nu tətbiq edin — idempotency açarları ilə dəyişikliklərin lokal yaddaşı (bax: «Offline Queue» məqaləsi). Növbə etibarlı Sync Engine-in təməlidir: onsuz sinxronizasiya dəyişikliklərin çatdırılmasını təmin etmir.

Addım 4: Conflict resolver seçin — sadə hallar üçün LWW, birgə redaktə üçün CRDT, biznes məntiqi üçün Custom merge. Qayda: resolver idempotent olmalıdır — eyni əməliyyatın təkrar tətbiqi eyni nəticəni verməlidir.

Addım 5: Monitorinq və metrikalar — hər sinxronizasiyanı qeyd edin: qeydlərin sayı, icra müddəti, konfliktlərin sayı, səhvlər. Firebase Crashlytics və ya Sentry (2025) real vaxtda sinxronizasiya səhvlərini izləməyə imkan verir.

Realm Team (2024) məlumatlarına görə, mobil tətbiq üçün tipik Sync Engine cihazda gündə 100–500 sinxronizasiya emal edir, sessiya başına orta hesabla 50–200 KB məlumat ötürür. Protokol optimallaşdırması — JSON əvəzinə Protobuf sıxılması — ötürülən məlumatın həcmini daha 40–60% azaldır.