একটি লার্নিং অ্যাপের জন্য অফলাইন সিঙ্ক ডিজাইন করুন: আপনি কীভাবে কনফ্লিক্ট রিজলভ করবেন?

Question

IT Interview Practice · Accepted Answer

অ্যাপটিকে **offline-first** হিসেবে বিবেচনা করুন: প্রতিটি ডিভাইস একটি লোকাল **replica**। স্টাডি অ্যাকশনগুলো একটি **local DB** এবং একটি append-only **op log** (outbox)-এ লেখা হয়; পুনরায় সংযোগ পেলে ডিভাইসটি **তার ops পুশ করে** এবং শেষ সিঙ্কের পর থেকে **সার্ভারের পরিবর্তনগুলো পুল করে**। কনফ্লিক্টগুলো কোনো একটি গ্লোবাল রুল দিয়ে **নয়** বরং **প্রতিটি ডেটা ফিল্ডের semantics** অনুযায়ী রিজলভ করা হয়।

**মেন্টাল মডেল:** এটিকে **git**-এর মতো ভাবুন — প্রতিটি ডিভাইস অফলাইনে থাকাকালীন লোকালি "commit" করে, এবং সিঙ্ক হলো একটি **merge**, overwrite নয়।

## Architecture

```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 থাকে, অফলাইনে থাকাকালীন কিউতে রাখা হয়। UI লোকালি read/write করে তাই কোনো নেটওয়ার্ক ছাড়াই এটি স্মুথ থাকে।
- **Sync service:** **cursor-based delta** সিঙ্ক — client cursor-এর পর থেকে ops পুশ করে, তার চেয়ে নতুন পরিবর্তনগুলো পুল করে। প্রতিটি সিঙ্ক শুধু **delta** সরায়, পুরো ডেটাসেট নয় → 5M ইউজার সস্তাই থাকে।
- **Conflict resolver:** per-field অর্থ অনুযায়ী merge করে (নিচে দেখুন)। **সার্ভারই source of truth**; স্মুথনেসের জন্য ক্লায়েন্ট প্রথমে রিজলভ করে, তারপর সার্ভার **একই** deterministic merge পুনরায় প্রয়োগ করে।

## Conflict resolution (the core)

ফোনের ক্লক **অনির্ভরযোগ্য** এবং দুটি ডিভাইস অফলাইনে একই রেকর্ড এডিট করতে পারে, তাই **"last write wins" (LWW) নীরবে ডেটা হারায়**। semantics অনুযায়ী রিজলভ করুন:

- **Monotonic fields** (lesson progress) → **max** নিন।
- **Additive counters** (total study time) → **delta যোগ করুন** (CRDT-style grow-only counter)।
- **সত্যিকারের "latest state"** (scroll position) → LWW গ্রহণযোগ্য।

```js
// op-এর একটি id আছে -> idempotently প্রয়োগ করুন (retries দুবার count করে না)। 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 একটি stale ডিভাইসকে দেরিতে `progress: 0.3` নিয়ে সিঙ্ক করে সার্ভারের `0.9`-কে **overwrite** করতে দিত → progress হারিয়ে যেত। `max` নেওয়া এবং `studiedMs` যোগ করা সিঙ্ককে **order-independent** করে তোলে — যখন লক্ষ লক্ষ ডিভাইস skewed ক্লক নিয়ে সিঙ্ক করে তখন নিরাপদ।

## Interview lens

ইন্টারভিউয়ার যাচাই করছেন আপনি জানেন কিনা যে **client ক্লক বিশ্বাস করা যায় না** (তাই পিওর timestamp LWW নয়), আপনি **সিঙ্ককে idempotent** করেন কিনা (op ids), এবং আপনি **ডেটার অর্থ অনুযায়ী merge** করেন কিনা। একটি **দুর্বল** উত্তর: "timestamp ব্যবহার করুন, last write wins।" একটি **শক্তিশালী** উত্তর: replica + op log + idempotency + per-field merge + সার্ভার source of truth হিসেবে — এবং LWW-এর **data-loss** ব্যর্থতাটি স্পষ্টভাবে নাম ধরে বলা।

## Trade-offs

LWW সস্তা কিন্তু lossy; semantic merge-এ per-field চিন্তা লাগে কিন্তু **কিছুই হারায় না**। পূর্ণ **CRDT/OT**-এর দিকে তখনই যান যখন আপনার সত্যিকারের collaborative editing দরকার (notes, documents) — এটি ব্যয়বহুল, তাই সবকিছুর জন্য এটি ব্যবহার করবেন না।

Architecture

Conflict resolution (the core)

Interview lens

Trade-offs

সম্পর্কিত প্রশ্ন