Bir öğrenme uygulaması için çevrimdışı senkronizasyon tasarlayın: çakışmaları nasıl çözersiniz?

Question

IT Interview Practice · Accepted Answer

Uygulamayı **offline-first** olarak ele alın: her cihaz yerel bir **replica**'dır. Çalışma eylemleri bir **local DB** ile birlikte yalnızca ekleme yapılan bir **op log**'a (outbox) yazılır; yeniden bağlanınca cihaz **op'larını push eder** ve son senkronizasyonundan bu yana **sunucu değişikliklerini pull eder**. Çakışmalar tek bir global kuralla **değil**, **her veri alanının semantiği** ile çözülür.

**Zihinsel model:** bunu **git** gibi düşünün — her cihaz çevrimdışıyken yerel olarak "commit" yapar ve senkronizasyon bir üzerine yazma değil, bir **merge**'dir.

## Mimari

```text
Device (offline)                        Server = source of truth
┌──────────────────┐   on reconnect     ┌───────────────────────────┐
│ Local DB (SQLite)│  push ops (delta)  │ Sync API  /sync           │
│ + Op log (outbox)│ ─────────────────▶ │  • idempotent by op.id    │
│ cursor = lastSeen│ ◀───────────────── │  • merge by semantics     │
└──────────────────┘  pull changes>cursor└───────────────────────────┘
                                         Progress DB (Postgres)
```

- **Local DB + op log:** her değişiklik, çevrimdışıyken sıraya alınan **istemci tarafından üretilen bir id'ye sahip değişmez bir op** + sürümdür. UI yerel olarak okur/yazar, böylece ağ olmadan akıcı kalır.
- **Sync service:** **cursor tabanlı delta** senkronizasyonu — istemci cursor'undan bu yana op'ları push et, ondan daha yeni değişiklikleri pull et. Her senkronizasyon tüm veri kümesini değil yalnızca **delta**'yı taşır → 5M kullanıcı ucuz kalır.
- **Conflict resolver:** alan bazlı anlama göre merge eder (aşağıda). **Sunucu source of truth'tur**; istemci akıcılık için önce çözer, ardından sunucu **aynı** deterministik merge'i yeniden uygular.

## Çakışma çözümü (çekirdek)

Telefon saatleri **güvenilmezdir** ve iki cihaz aynı kaydı çevrimdışı düzenleyebilir, bu yüzden **"last write wins" (LWW) sessizce veri kaybeder**. Semantiğe göre çözün:

- **Monotonik alanlar** (ders ilerlemesi) → **max**'ı al.
- **Toplamsal sayaçlar** (toplam çalışma süresi) → **delta'yı ekle** (CRDT tarzı yalnızca büyüyen sayaç).
- **Gerçek "en son durum"** (kaydırma konumu) → LWW kabul edilebilir.

```js
// op'un bir id'si var -> idempotent uygula (yeniden denemeler iki kez saymaz). clientTs GÜVENİLMEZ.
function mergeProgress(server, op) {
  return {
    // progress yalnızca artar -> max: geç kalan eski bir op onu asla geriye çekmez
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs toplamsal bir sayaçtır -> delta'yı ekle, üzerine yazma
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Burada, düz LWW geç senkronize olan bayat bir cihazın `progress: 0.3` değeriyle sunucunun `0.9` değerinin **üzerine yazmasına** izin verir → kaybedilmiş ilerleme. `max` almak ve `studiedMs`'i toplamak senkronizasyonu **sıra bağımsız** yapar — milyonlarca cihaz kaymış saatlerle senkronize olurken güvenlidir.

## Mülakat merceği

Mülakatı yapan kişi, **istemci saatlerinin güvenilemeyeceğini** (yani saf timestamp LWW değil) bilip bilmediğinizi, **senkronizasyonu idempotent** yapıp yapmadığınızı (op id'leri) ve **veri anlamına göre merge** edip etmediğinizi araştırıyor. **Zayıf** bir cevap: "timestamp kullan, last write wins." **Güçlü** bir cevap: replica + op log + idempotency + alan bazlı merge + source of truth olarak sunucu — ve LWW'nin **veri kaybı** başarısızlığını açıkça adlandırmak.

## Ödünleşimler

LWW ucuzdur ama kayıplıdır; semantik merge alan bazlı düşünme gerektirir ama **hiçbir şey kaybetmez**. Tam **CRDT/OT**'ye yalnızca gerçek işbirlikçi düzenlemeye (notlar, dökümanlar) ihtiyaç duyduğunuzda başvurun — maliyetlidir, bu yüzden her şey için kullanmayın.

Mimari

Çakışma çözümü (çekirdek)

Mülakat merceği

Ödünleşimler

İlgili sorular