შეიმუშავეთ offline sync სასწავლო აპლიკაციისთვის: როგორ წყვეტთ კონფლიქტებს?

Question

IT Interview Practice · Accepted Answer

აპლიკაცია მოეპყარით როგორც **offline-first**-ს: ყოველი მოწყობილობა არის ლოკალური **replica**. სასწავლო ქმედებები იწერება **local DB**-ში პლუს append-only **op log**-ში (outbox); ხელახლა დაკავშირებისას მოწყობილობა **აგზავნის თავის ops-ს** და **იღებს სერვერის ცვლილებებს** ბოლო sync-ის შემდეგ. კონფლიქტები წყდება **არა** ერთი გლობალური წესით, არამედ **თითოეული data ველის სემანტიკით**.

**აზროვნების მოდელი:** წარმოიდგინეთ ისე, როგორც **git** — ყოველი მოწყობილობა offline-ის დროს ლოკალურად „აკეთებს commit-ს", ხოლო sync არის **merge**, და არა overwrite.

## არქიტექტურა

```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:** ყოველი ცვლილება არის **immutable op კლიენტის მიერ გენერირებული id-ით** + version, რიგში ჩაყენებული offline-ის დროს. UI კითხულობს/წერს ლოკალურად, ამიტომ რჩება გლუვი ქსელის გარეშე.
- **Sync service:** **cursor-based delta** sync — აგზავნის ops-ს კლიენტის cursor-ის შემდეგ, იღებს მასზე ახალ ცვლილებებს. ყოველი sync გადააქვს მხოლოდ **delta**, და არა მთელ dataset-ს → 5M მომხმარებელი რჩება იაფი.
- **Conflict resolver:** merge-ს აკეთებს ველების მიხედვით მათი მნიშვნელობით (ქვემოთ). **სერვერი არის source of truth**; კლიენტი პირველი წყვეტს გლუვობისთვის, შემდეგ სერვერი ხელახლა იყენებს **იმავე** დეტერმინისტულ merge-ს.

## კონფლიქტების გადაწყვეტა (ბირთვი)

ტელეფონის საათები **არასანდოა** და ორ მოწყობილობას შეუძლია იმავე ჩანაწერის რედაქტირება offline-ში, ამიტომ **„last write wins" (LWW) მდუმარედ კარგავს data-ს**. გადაწყვიტეთ სემანტიკით:

- **მონოტონური ველები** (გაკვეთილის პროგრესი) → აიღეთ **max**.
- **დამატებითი counter-ები** (სულ სასწავლო დრო) → **დაამატეთ delta** (CRDT-სტილის grow-only counter).
- **ნამდვილი „უახლესი მდგომარეობა"** (scroll position) → LWW მისაღებია.

```js
// op-ს აქვს id -> გამოიყენე იდემპოტენტურად (retries არ ითვლის ორმაგად). clientTs არ არის სანდო.
function mergeProgress(server, op) {
  return {
    // progress მხოლოდ იზრდება -> max: დაგვიანებული ძველი op არასდროს გადაათრევს უკან
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs არის დამატებითი counter -> დაამატე delta, ნუ გადააწერ
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

აქ, უბრალო LWW მისცემდა უფლებას მოძველებულ მოწყობილობას, რომელიც გვიან sync-ს აკეთებს `progress: 0.3`-ით, **გადაეწერა** სერვერის `0.9` → დაკარგული პროგრესი. `max`-ის აღება და `studiedMs`-ის შეკრება sync-ს ხდის **order-independent**-ს — უსაფრთხოა, როცა მილიონობით მოწყობილობა sync-ს აკეთებს დამახინჯებული საათებით.

## ინტერვიუს პრიზმა

ინტერვიუერი ამოწმებს, იცით თუ არა, რომ **კლიენტის საათები ვერ იქნება სანდო** (ანუ არა სუფთა timestamp LWW), აქცევთ თუ არა **sync-ს იდემპოტენტურად** (op ids), და აკეთებთ თუ არა **merge-ს data-ს მნიშვნელობით**. **სუსტი** პასუხი: „გამოიყენე timestamps, last write wins." **ძლიერი** პასუხი: replica + op log + იდემპოტენტურობა + per-field merge + სერვერი როგორც source of truth — და LWW-ის **data-loss** ჩავარდნის აშკარად დასახელება.

## Trade-off-ები

LWW იაფია, მაგრამ დაკარგვასთან დაკავშირებული; სემანტიკური merge საჭიროებს per-field ფიქრს, მაგრამ **არაფერს კარგავს**. სრულ **CRDT/OT**-ს მიმართეთ მხოლოდ მაშინ, როცა გჭირდებათ ნამდვილი collaborative editing (ჩანაწერები, დოკუმენტები) — ის ძვირია, ამიტომ ნუ გამოიყენებთ ყველაფრისთვის.

არქიტექტურა

კონფლიქტების გადაწყვეტა (ბირთვი)

ინტერვიუს პრიზმა

Trade-off-ები

დაკავშირებული კითხვები