Sync Engine: Temel Kavramlar, Türler ve Çalışma Mekanizmaları

Senkronizasyon motoru nedir?

Sync Engine — yerel veritabanı ile uzak API arasında, veri akışını her iki yönde yöneten bir mimari katmandır. Görevleri: değişiklikleri izlemek, sunucuya göndermek, sunucudan değişiklikleri almak ve çatışmaları çözmek. Kullanıcı yerel verilerle etkileşime girerken, Sync Engine bunları sunucuyla sorunsuz bir şekilde senkronize eder.

Sync Engine yerleşik (Firebase Firestore, Couchbase Lite, Realm) veya özel — belirli iş mantığı için yazılmış olabilir. Yerleşik motorlar, kullanıma hazır offline-first işlevselliği ve çatışma çözümü sunar. Özel motorlar, veri formatı, senkronizasyon protokolü ve çatışma politikası üzerinde tam kontrol sağlar.

Sravana Karthik (2024)’e göre, «Mobile Sync Engine Design Patterns» kitabının yazarı, özel bir Sync Engine, özel birleştirme kurallarının kritik olduğu karmaşık iş mantığına (finans, sağlık, IoT) sahip uygulamalar için uygundur. Tipik senaryolar (notlar, sohbetler, beslemeler) için yerleşik Firestore veya Realm yeterlidir.

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 arayüz, Sync Engine’in minimum sözleşmesini açıklar: pull (sunucudan değişiklikleri yükleme), push (yerel değişiklikleri gönderme), resolve (çatışmaları yönetme) ve observe (senkronizasyon durumunu izleme). Bu soyutlama, sunum katmanını değiştirmeden uygulamayı değiştirmeye olanak tanır.

Senkronizasyon türleri: tam, artımlı ve push

Tam senkronizasyon (Full sync) — her oturum sunucudan tüm veri kümesini yükler. Uygulaması basittir, ancak büyük hacimler için kabul edilemez: uygulamayı her açışınızda 10.000 kaydı indirmek trafik ve pil tüketir. Tam senkronizasyon, seyrek güncellemeleri olan referans verileri (ülke listesi) için uygundur.

Artımlı senkronizasyon — yalnızca son senkronizasyondan bu yana değiştirilen kayıtlar aktarılır. Sunucu, her kayıt veya tüm küme için son değişiklik zaman damgasını saklar. İstemci lastSyncTimestamp gönderir ve yalnızca updated_at > bu değer olan kayıtları alır. Instagram Engineering (2024)’e göre, artımlı senkronizasyon, tam senkronizasyona kıyasla veri aktarım hacmini %97 oranında azaltır.

Push senkronizasyonu (sunucu başlatmalı) — sunucu, FCM (Firebase Cloud Messaging), WebSocket veya SSE (Server-Sent Events) aracılığıyla istemciye senkronizasyon gerektiğini bildirir. İstemci, periyodik yoklama için kaynak israf etmez. Push senkronizasyonu, gerçek zamanlı uygulamalar (sohbet, bildirim, beğeni) için en uygun seçimdir. Google Firebase Firestore, HTTP polling’e otomatik geri dönüşlü WebSocket ile gerçek zamanlı senkronizasyon kullanır.

Karma yaklaşım — türlerin bir kombinasyonu: uygulama başlatılırken temel veriler için tam senkronizasyon, ardından güncellemeler için artımlı senkronizasyon ve kritik olaylar için FCM aracılığıyla push senkronizasyonu. Bu, hem hız hem de kaynak tasarrufu sağlar.

Artımlı senkronizasyon — kontrol noktaları ve delta nasıl çalışır

Kontrol noktası (Checkpoint) — istemcinin senkronizasyon oturumları arasında sakladığı bir değerdir. Genellikle son başarıyla senkronize edilmiş kaydın updated_at değeridir. Bir sonraki senkronizasyonda, istemci kontrol noktasını sunucuya gönderir ve sunucu, kontrol noktasından sonra updated_at değerine sahip tüm kayıtları döndürür. İmleç tabanlı sayfalama — sunucunun verilerle birlikte bir imleç (sonraki sayfaya işaretçi) döndürdüğü gelişmiş bir sürümdür.

Delta senkronizasyonu — sunucu, mevcut veri durumu ile istemcinin en son gördüğü anlık görüntü arasındaki farkı hesaplar. Tüm kayıtları göndermek yerine yalnızca işlemler (insert, update, delete) aktarılır. Bu, yalnızca birkaç kaydın değiştirildiği büyük veri kümeleri için özellikle etkilidir. Google Drive API (2025), dosya delta senkronizasyonu için pageToken ile changes.list kullanır.

«Gecikmeli delta» stratejisi — mobil istemcide değişiklikler hemen gönderilmez, çevrimdışı kuyrukta arabelleğe alınır. Eşik değerine (10 işlem veya 30 saniye) ulaşıldığında, bir delta paketi oluşturulur ve sunucuya gönderilir. Dropbox Mobile Engineering (2024)’e göre, delta toplu işleme, HTTP isteklerinin sayısını %65 ve pil tüketimini %12 azaltmıştır.

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, uzun listeler için hem zaman damgasını hem de sayfalama imlecini saklar. İki parametreli kontrol noktası, büyük veri kümeleri senkronize edilirken hiçbir kaydın atlanmamasını veya tekrarlanmamasını garanti eder.

Push senkronizasyonu — WebSocket ve FCM ile anlık senkronizasyon

WebSocket — istemci ve sunucu arasında kalıcı çift yönlü bir bağlantıdır. Sunucu, veriler değiştiğinde güncellemeleri hemen gönderir. WebSocket, gerçek zamanlı uygulamalar (sohbet, akış, işbirliği) için idealdir. Dezavantajı: bağlantıyı sürdürmek için pil ve trafik tüketimi (kalp atışı). Android’de OkHttp WebSocket ve iOS’ta URLSessionWebSocketTask — yerleşik uygulamalar.

Firebase Cloud Messaging (FCM) — sunucunun kullanıcıya göstermek için değil, senkronizasyonu tetiklemek için gönderdiği push bildirimleridir. Bir sessiz push (veri mesajı) alındığında, uygulama uyanır ve Sync Engine’i başlatır. FCM kalıcı bir bağlantı gerektirmez ve seyrek bildirimler için WebSocket’ten daha ekonomiktir.

SSE (Server-Sent Events) — sunucunun istemciye olayları gönderdiği tek yönlü bir kanaldır. WebSocket’ten uygulaması daha basittir ancak çift yönlü iletişimi desteklemez. EventSource API (JavaScript) ve OkHttp SSE (Android) — popüler kütüphaneler. SSE, istemcinin aynı kanal üzerinden veri göndermesi gerekmediğinde yeni verilerle ilgili bildirimler için uygundur.

WhatsApp Engineering (2024)’e göre, onların Sync Engine’i, etkin oturum için WebSocket ve arka planda uygulamayı uyandırmak için FCM kombinasyonunu kullanır: WebSocket, 5 dakika hareketsizlikten sonra bağlantıyı keser ve sonraki güncellemeler sessiz push aracılığıyla iletilir.

Anlık görüntü senkronizasyonu ve veri sürümleme

Anlık görüntü tabanlı senkronizasyon — sunucu periyodik olarak verilerin tam bir anlık görüntüsünü oluşturur ve bir sürüm atar. İstemci mevcut sürüm numarasını saklar. Güncel değilse — yeni bir anlık görüntü indirir. Bu basit ve güvenilir bir stratejidir, ancak sık değişiklikler için verimsizdir — her seferinde tüm veri kümesi indirilir.

Kayıt bazında sürümleme — her kaydın bir version alanı vardır. Senkronizasyon sırasında istemci tüm kayıtların sürümlerini gönderir ve sunucu yalnızca sürümü değişenleri döndürür. Bu, anlık görüntü senkronizasyonundan daha verimlidir, ancak istemcide sürümlerin saklanmasını gerektirir. Vektör Saatleri (Vector Clocks) — her düğümün kendi sürümünü atadığı ve çatışmaların kısmi sırayla çözüldüğü dağıtık sistemler için gelişmiş bir tekniktir.

Artımlı diff ile anlık görüntü — karma bir yaklaşım: seyrek tam anlık görüntüler (günde bir kez) + aralarında artımlı senkronizasyon. Uzun bir aradan sonra başlatırken istemci bir anlık görüntü yükler ve sık senkronizasyonlarda yalnızca delta yükler. Git benzeri yaklaşım — her veri commit’inin bir karması vardır ve istemci hangi commit’ten başlayacağını bilir. Bu, Couchbase Lite Sync Gateway’de (2024) uygulanmıştır ve güvenilirlik için altın standarttı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)
    }

Sürüm çözümleme kuralı: sürümler eşleşirse — değişiklik yoktur. Yerel sürüm daha yeniyse — yerel kazanır. Sunucu sürümü daha yeniyse — sunucu kazanır. Yalnızca sürümler eşit ancak veriler farklı olduğunda — çatışma çözücü çağrılır. Sürüm bayrağıyla Last Write Wins — en basit ancak güvenilir stratejidir.

Mobil Uygulama İçin Sync Engine Nasıl Oluşturulur

Adım 1: Veri modelini tanımlayın — hangi varlıkların senkronize edildiğini, ne sıklıkta değiştiklerini ve hacimlerini belirleyin. Her varlık için stratejiyi (artımlı / tam / push) ve kabul edilebilir senkronizasyon gecikmesini tanımlayın.

Adım 2: Bir protokol seçin — kontrol noktalarıyla REST, Subscriptions ile GraphQL veya çift yönlü akışla gRPC. GraphQL Subscriptions — modern uygulamalar için popüler bir seçim: hem pull hem de push için tek bir protokol. Apollo Client (2025), cihaz önbelleği aracılığıyla çevrimdışı senkronizasyonu destekler.

Adım 3: Bir çevrimdışı kuyruk uygulayın — kimlik gücü anahtarlarıyla yerel değişiklik depolama («Offline Queue» makalesine bakın). Kuyruk, güvenilir bir Sync Engine’in temelidir: onsuz senkronizasyon, değişikliklerin teslimini garanti etmez.

Adım 4: Bir çatışma çözücü seçin — basit durumlar için LWW, işbirlikçi düzenleme için CRDT, iş mantığı için özel birleştirme. Kural: çözücü kimlik gücüne sahip olmalıdır — aynı işlemi tekrar uygulamak aynı sonucu vermelidir.

Adım 5: İzleme ve metrikler — her senkronizasyonu kaydedin: kayıt sayısı, yürütme süresi, çatışma sayısı, hatalar. Firebase Crashlytics veya Sentry (2025), senkronizasyon hatalarını gerçek zamanlı olarak izlemeye olanak tanır.

Realm Team (2024)’e göre, tipik bir mobil uygulama Sync Engine’i, cihaz başına günde 100–500 senkronizasyon işler ve oturum başına ortalama 50–200 KB veri aktarır. Protokol optimizasyonu — JSON yerine Protobuf sıkıştırması kullanmak — veri aktarım hacmini %40–60 daha azaltır.