ایپ کو سمجھیں: ہر device ایک local ہے۔ مطالعے کے actions ایک کے ساتھ ساتھ ایک append-only (outbox) میں لکھے جاتے ہیں؛ دوبارہ connect ہونے پر device اور اپنے آخری sync کے بعد کی ۔ Conflicts کسی ایک global rule سے بلکہ کے مطابق حل کیے جاتے ہیں۔
ایپ کو سمجھیں: ہر device ایک local ہے۔ مطالعے کے actions ایک کے ساتھ ساتھ ایک append-only (outbox) میں لکھے جاتے ہیں؛ دوبارہ connect ہونے پر device اور اپنے آخری sync کے بعد کی ۔ Conflicts کسی ایک global rule سے بلکہ کے مطابق حل کیے جاتے ہیں۔
ذہنی ماڈل: اسے git کی طرح سمجھیں — ہر device offline ہوتے ہوئے مقامی طور پر "commit" کرتا ہے، اور sync ایک merge ہے، overwrite نہیں۔
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)
فون کی گھڑیاں ناقابلِ اعتبار ہوتی ہیں اور دو devices offline ہوتے ہوئے ایک ہی record میں ترمیم کر سکتے ہیں، اس لیے "last write wins" (LWW) خاموشی سے data کھو دیتا ہے۔ semantics کے مطابق حل کریں:
// op کے پاس ایک id ہے -> idempotently apply کریں (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 ایک بوسیدہ device کو، جو دیر سے progress: 0.3 کے ساتھ sync کر رہا ہے، server کے 0.9 کو overwrite کرنے دے گا → progress ضائع۔ max لینا اور studiedMs کو جوڑنا sync کو order-independent بنا دیتا ہے — جب لاکھوں devices خراب گھڑیوں کے ساتھ sync کریں تو یہ محفوظ ہے۔
انٹرویو لینے والا یہ جانچ رہا ہے کہ کیا آپ جانتے ہیں کہ client clocks پر بھروسہ نہیں کیا جا سکتا (لہٰذا خالص timestamp LWW نہیں)، کیا آپ sync کو idempotent بناتے ہیں (op ids)، اور کیا آپ data کے معنی کے مطابق merge کرتے ہیں۔ ایک کمزور جواب: "timestamps استعمال کریں، last write wins۔" ایک مضبوط جواب: replica + op log + idempotency + per-field merge + server بطور source of truth — اور LWW کی data-loss ناکامی کو واضح طور پر بیان کرنا۔
LWW سستا مگر نقصان دہ ہے؛ semantic merge کو ہر field پر سوچنے کی ضرورت ہے مگر یہ کچھ نہیں کھوتا۔ مکمل CRDT/OT کی طرف صرف تب جائیں جب آپ کو حقیقی collaborative editing (notes، documents) درکار ہو — یہ مہنگا ہے، اس لیے ہر چیز کے لیے اسے استعمال نہ کریں۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں