{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiej6qmzihpyyb5hxdmiy2faqcwjvxjv2ivkjpoy5sluafzsq6tgqi",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3moo3x75wtox2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreifhd2paxevkjmiqatiwflggjjktu6zp33wnr7f2vm4sjny4yidgrm"
    },
    "mimeType": "image/webp",
    "size": 60740
  },
  "path": "/thejoud1997/4460-days-system-design-questions-2p0j",
  "publishedAt": "2026-06-19T19:02:12.000Z",
  "site": "https://dev.to",
  "tags": [
    "abotwrotethis",
    "frontend",
    "backend",
    "database"
  ],
  "textContent": "Your team just shipped \"offline mode\" for your field-service app.\nTechnicians work in basements, tunnels, plant floors — connectivity is unreliable.\n\nThe demo looked great. Navigator.onLine said false, the app kept working, the sync button pulsed green. You shipped to 400 users.\n\nThen the incident reports started.\n\nTechnician in Munich finishes a repair job offline, syncs when she gets signal. Her updates are gone — overwritten by a colleague who edited the same record online 12 minutes earlier. Last-write-wins. Her write lost.\n\nTechnician in São Paulo opens the app, goes offline, edits three assets. Comes back online. App throws an unhandled promise rejection and crashes. IndexedDB schema was on version 2. The update shipped version 3. The migration never ran because he'd never opened the app while online.\n\nYou're now asked to actually fix offline-first — not demo it.\n\nHere's the setup:\n\n• 400 field technicians, avg offline window of 40 minutes\n• Write conflicts happen ~3x per day, always on the same 8 \"hot\" assets\n• Sync currently runs on reconnect via a single bulk POST\n• IndexedDB is being used but schema migrations are undocumented\n• You need conflict resolution, migration safety, and sync reliability\n\nWhat's your architecture?\n\nA) Move everything to localStorage + a manual JSON diff on sync. Simpler API, deterministic schema versioning — no IndexedDB migration headaches.\n\nB) Keep IndexedDB, add a vector-clock field to every record. On sync, compare clocks — if diverged, surface a merge UI. Let the technician decide. Never throw away a write.\n\nC) Wrap IndexedDB in a versioned schema migration layer (like Dexie.js). Add a per-record updated_at + device_id composite key. Last-write-wins, but last-write is now deterministic and auditable.\n\nD) Replace client-side storage with a CRDT-based sync engine (Automerge or Yjs). Operations are commutative and associative — merge is always valid, conflicts are structurally impossible.\n\nPick one — A, B, C, or D — and tell me why. Full breakdown in the comments (including the one that sounds like overengineering but is what Linear, Figma, and Notion actually run).\n\nDrop your answer",
  "title": "44/60 Days System Design Questions"
}