ਐਪ ਨੂੰ ਮੰਨੋ: ਹਰ device ਇੱਕ ਲੋਕਲ ਹੈ। Study actions ਨੂੰ ਇੱਕ ਦੇ ਨਾਲ-ਨਾਲ ਇੱਕ append-only (outbox) ਵਿੱਚ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ; reconnect ਹੋਣ 'ਤੇ device ਅਤੇ ਆਪਣੇ ਪਿਛਲੇ sync ਤੋਂ ਬਾਅਦ ਦੇ । Conflicts ਨੂੰ ਕਿਸੇ ਇੱਕ global rule ਨਾਲ ਬਲਕਿ ਹਰ ਨਾਲ ਹੱਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਐਪ ਨੂੰ ਮੰਨੋ: ਹਰ device ਇੱਕ ਲੋਕਲ ਹੈ। Study actions ਨੂੰ ਇੱਕ ਦੇ ਨਾਲ-ਨਾਲ ਇੱਕ append-only (outbox) ਵਿੱਚ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ; reconnect ਹੋਣ 'ਤੇ device ਅਤੇ ਆਪਣੇ ਪਿਛਲੇ sync ਤੋਂ ਬਾਅਦ ਦੇ । Conflicts ਨੂੰ ਕਿਸੇ ਇੱਕ global rule ਨਾਲ ਬਲਕਿ ਹਰ ਨਾਲ ਹੱਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
Mental model: ਇਸ ਨੂੰ 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)
ਫੋਨ ਦੀਆਂ clocks ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਹੁੰਦੀਆਂ ਅਤੇ ਦੋ devices offline ਹੋਣ ਵੇਲੇ ਇੱਕੋ record ਨੂੰ edit ਕਰ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ "last write wins" (LWW) ਚੁੱਪ-ਚਾਪ data ਗੁਆ ਦਿੰਦਾ ਹੈ। Semantics ਦੇ ਹਿਸਾਬ ਨਾਲ resolve ਕਰੋ:
// op has an id -> apply idempotently (retries don't double-count). clientTs is NOT trusted.
function mergeProgress(server, op) {
return {
// progress only increases -> max: a late old op never drags it backward
progress: Math.max(server.progress ?? 0, op.progress),
// studiedMs is an additive counter -> add the delta, don't overwrite
studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
};
}
ਇੱਥੇ, plain LWW ਇੱਕ stale device ਨੂੰ, ਜੋ ਦੇਰ ਨਾਲ progress: 0.3 ਨਾਲ sync ਕਰਦਾ ਹੈ, server ਦੇ 0.9 ਨੂੰ overwrite ਕਰਨ ਦੇਵੇਗਾ → progress ਗੁੰਮ। max ਲੈਣਾ ਅਤੇ studiedMs ਨੂੰ sum ਕਰਨਾ sync ਨੂੰ order-independent ਬਣਾ ਦਿੰਦਾ ਹੈ — ਸੁਰੱਖਿਅਤ ਜਦੋਂ ਲੱਖਾਂ devices skewed clocks ਨਾਲ sync ਕਰਦੇ ਹਨ।
Interviewer ਇਹ ਪਰਖ ਰਿਹਾ ਹੈ ਕਿ ਕੀ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ client clocks 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ (ਇਸ ਲਈ pure timestamp LWW ਨਹੀਂ), ਕੀ ਤੁਸੀਂ sync ਨੂੰ idempotent ਬਣਾਉਂਦੇ ਹੋ (op ids), ਅਤੇ ਕੀ ਤੁਸੀਂ data ਦੇ ਅਰਥ ਦੇ ਹਿਸਾਬ ਨਾਲ merge ਕਰਦੇ ਹੋ। ਇੱਕ ਕਮਜ਼ੋਰ ਜਵਾਬ: "timestamps ਵਰਤੋ, last write wins।" ਇੱਕ ਮਜ਼ਬੂਤ ਜਵਾਬ: replica + op log + idempotency + per-field merge + server as source of truth — ਅਤੇ LWW ਦੀ data-loss ਵਾਲੀ ਖਰਾਬੀ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਨਾਮ ਦੇਣਾ।
LWW ਸਸਤਾ ਹੈ ਪਰ lossy ਹੈ; semantic merge ਨੂੰ per-field ਸੋਚ ਦੀ ਲੋੜ ਹੈ ਪਰ ਇਹ ਕੁਝ ਨਹੀਂ ਗੁਆਉਂਦਾ। ਪੂਰਾ CRDT/OT ਸਿਰਫ਼ ਉਦੋਂ ਵਰਤੋ ਜਦੋਂ ਤੁਹਾਨੂੰ ਸੱਚੀ collaborative editing (notes, documents) ਦੀ ਲੋੜ ਹੋਵੇ — ਇਹ ਮਹਿੰਗਾ ਹੈ, ਇਸ ਲਈ ਇਸ ਨੂੰ ਹਰ ਚੀਜ਼ ਲਈ ਨਾ ਵਰਤੋ।
ਵਿਸਤ੍ਰਿਤ ਜਵਾਬਾਂ ਨਾਲ IT ਇੰਟਰਵਿਊ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ — ਜੂਨੀਅਰ ਤੋਂ ਸੀਨੀਅਰ ਤੱਕ।
ਦਾਨ ਕਰੋ