Σχεδιάστε offline sync για μια εκπαιδευτική εφαρμογή: πώς επιλύετε τα conflicts;

Question

IT Interview Practice · Accepted Answer

Αντιμετωπίστε την εφαρμογή ως **offline-first**: κάθε συσκευή είναι ένα τοπικό **replica**. Οι ενέργειες μελέτης γράφονται σε μια **τοπική DB** συν ένα append-only **op log** (outbox)· κατά την επανασύνδεση η συσκευή **κάνει push τα ops της** και **κάνει pull τις αλλαγές του server** από το τελευταίο της sync. Τα conflicts επιλύονται **όχι** με έναν καθολικό κανόνα αλλά με τη **σημασιολογία κάθε πεδίου δεδομένων**.

**Νοητικό μοντέλο:** σκεφτείτε το σαν **git** — κάθε συσκευή κάνει "commit" τοπικά ενώ είναι offline, και το 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 με ένα client-generated id** + version, στην ουρά ενώ είναι offline. Το UI διαβάζει/γράφει τοπικά ώστε να παραμένει ομαλό χωρίς δίκτυο.
- **Sync service:** **cursor-based delta** sync — push τα ops από τον client cursor, pull τις αλλαγές νεότερες από αυτόν. Κάθε sync μετακινεί μόνο το **delta**, όχι όλο το dataset → 5M χρήστες παραμένει φθηνό.
- **Conflict resolver:** κάνει merge ανά σημασία πεδίου (παρακάτω). Ο **server είναι το source of truth**· ο client επιλύει πρώτος για ομαλότητα, μετά ο server ξανα-εφαρμόζει το **ίδιο** ντετερμινιστικό merge.

## Επίλυση conflict (ο πυρήνας)

Τα ρολόγια των τηλεφώνων είναι **αναξιόπιστα** και δύο συσκευές μπορούν να επεξεργαστούν την ίδια εγγραφή offline, οπότε το **"last write wins" (LWW) χάνει σιωπηλά δεδομένα**. Επιλύστε με σημασιολογία:

- **Monotonic πεδία** (πρόοδος μαθήματος) → πάρτε το **max**.
- **Additive counters** (συνολικός χρόνος μελέτης) → **προσθέστε το delta** (grow-only counter τύπου CRDT).
- **Πραγματικό "latest state"** (θέση scroll) → το LWW είναι αποδεκτό.

```js
// το op έχει ένα id -> εφαρμογή idempotent (τα retries δεν διπλομετρούν). Το clientTs ΔΕΝ είναι αξιόπιστο.
function mergeProgress(server, op) {
  return {
    // η progress μόνο αυξάνεται -> max: ένα καθυστερημένο παλιό op δεν την τραβάει ποτέ πίσω
    progress: Math.max(server.progress ?? 0, op.progress),
    // το studiedMs είναι additive counter -> πρόσθεσε το delta, μην κάνεις overwrite
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Εδώ, το απλό LWW θα άφηνε μια ξεπερασμένη συσκευή που κάνει sync αργά με `progress: 0.3` να **overwrite** το `0.9` του server → χαμένη πρόοδος. Παίρνοντας το `max` και αθροίζοντας το `studiedMs` κάνει το sync **ανεξάρτητο σειράς** — ασφαλές όταν εκατομμύρια συσκευές κάνουν sync με μετατοπισμένα ρολόγια.

## Interview lens

Ο interviewer διερευνά αν ξέρετε ότι **τα ρολόγια του client δεν είναι αξιόπιστα** (άρα όχι καθαρό timestamp LWW), αν κάνετε το **sync idempotent** (op ids), και αν κάνετε **merge ανά σημασία δεδομένων**. Μια **αδύναμη** απάντηση: "χρησιμοποίησε timestamps, last write wins." Μια **δυνατή** απάντηση: replica + op log + idempotency + per-field merge + server ως source of truth — και ονομάζοντας ρητά την αποτυχία **απώλειας δεδομένων** του LWW.

## Trade-offs

Το LWW είναι φθηνό αλλά χάνει δεδομένα· το semantic merge χρειάζεται σκέψη ανά πεδίο αλλά **δεν χάνει τίποτα**. Καταφύγετε σε πλήρες **CRDT/OT** μόνο όταν χρειάζεστε πραγματικό collaborative editing (σημειώσεις, έγγραφα) — είναι δαπανηρό, οπότε μην το χρησιμοποιείτε για τα πάντα.

Αρχιτεκτονική

Επίλυση conflict (ο πυρήνας)

Interview lens

Trade-offs

Σχετικές ερωτήσεις