Adobe Creative Cloud Offline Sync And Conflict Resolution

What's being tested

The interviewer is probing your ability to design a robust offline-first sync system for large, binary-rich assets and to reason about conflict detection and resolution strategies that scale across many devices. They want evidence you understand synchronization primitives (versioning, diffs, chunking), consistency models (eventual vs causal), tradeoffs between automatic merge and user-driven resolution, and operational concerns (bandwidth, storage, GC, security). Expect to justify choices for Adobe-scale workloads: large files, frequent offline edits, and complex document models.

Core knowledge

Offline-first architecture: clients must queue local edits, persist logs, and resumable uploads; prefer append-only local operation logs for durability and conflict replay after reconnect.
Versioning primitives: know vector clocks and Lamport timestamps; vector clocks capture causality but grow O(#devices); Lamport is compact but only gives partial ordering, not concurrency detection.
Three-way merge: for file/text, compute diffs against a common ancestor using Myers diff or similar, apply a three-way merge; binary assets often can’t auto-merge and require version branching or domain-specific merges.
CRDTs vs OT: CRDTs (state-based or op-based) provide strong eventual consistency without central coordination; Operational Transform (OT) works for low-latency, central-server-mediated real-time edits but is complex to implement for rich binary models.
Delta sync and chunking: use content-defined chunking (Rabin fingerprinting) or fixed-size chunks (e.g., 4MB) plus content-addressable storage to send only changed chunks; rsync-style rolling checksums speed up detecting deltas for large files.
Integrity & history: maintain Merkle trees or content-addressed hashes to detect divergence and enable efficient subtree comparisons; store immutable versions and metadata to build history and allow rollbacks.
Conflict strategies: automatic merge (for text or structured JSON), last-write-wins (LWW) for cheap resolution with metadata, manual resolution with clear UI for binary/complex conflicts, and application-specific merge for layered documents (e.g., PSD layer merges).
Tombstones & GC: deleted items need tombstones to avoid resurrecting on replay; retain tombstones for a retention window (e.g., 30–90 days) then compact; GC must be careful to avoid losing concurrent edits.
Scalability numbers & tradeoffs: vector clocks are fine for up to ~100 concurrent devices; beyond that, prefer CRDTs or server-assigned monotonically increasing version IDs. Chunk sizes around 1–8MB balance network RTT and dedup effectiveness.
Resumable / partial upload mechanics: use multipart upload and HTTP Range or protocol buffers with chunk checksums; ensure idempotent chunk PUTs (idempotency keys) and transactional commit of assembled object.
Security / privacy: encrypt in transit and at rest; if using client-side encryption, syncing metadata for merge becomes harder — you may need server-side deterministic metadata or homomorphic-friendly approaches.
Metadata vs content sync: sync file metadata (rename, move, permission) as separate operations with their own sequencing; moves/renames are cheap but cause conflicts when simultaneous.

Worked example — "Design offline sync and conflict resolution for Creative Cloud"

Frame: first ask clarifying questions — expected scale (millions of users?), typical file sizes, acceptable conflict latency, and whether some documents are cloud-native (structured) versus opaque binaries. Skeleton: (1) client-side durability and edit-log + resumable chunked uploads; (2) server-side authoritative version store with content-addressed chunks and Merkle index; (3) conflict detection via version vectors or change ancestry, with three resolution modes (auto, app-merge, manual). Tradeoff: decide between vector clocks (good causality detection but metadata bloat) and server-assigned monotonic IDs (scales, but loses causality info); you’d pick server-assigned IDs plus causal metadata for collaborative docs and vector clocks only for small-device sets. Explicitly flag UX: for binary assets prefer preserving both branches and surfacing to user to choose or merge via app. Close: mention monitoring (sync failure rates, p99 latency), and say “if I had more time I’d prototype CRDTs for cloud-native PSD layers and measure metadata growth and merge correctness.”

A second angle — real-time collaborative cloud-native documents

When documents are cloud-native (structured layers, editable components), prioritize low-latency convergence and per-operation commutativity. Here you trade storage overhead for fewer user conflicts: choose op-based CRDTs (smaller ops, causal delivery via server) or server-mediated OT for strict transform ordering. Also add hybrid: real-time OT for live sessions, and CRDT or three-way-merge for offline edits converging later. Emphasize preserving intent (causality) over naïve LWW, and plan for partial offline sessions where operations must be buffered and replayed with causal metadata.

Common pitfalls

Pitfall: Treating every file like plain text.
Binary, layered, and application-specific documents often need domain-aware merging or branch-preserve UX. A naive three-way merge will corrupt layered PSDs or lose edit intent.

Pitfall: Relying on vector clocks for global scale.
Vector clocks accurately detect concurrency but metadata size grows with devices; at Adobe scale, they cause bandwidth and storage bloat unless bounded or summarized.

Pitfall: Hiding conflict resolution from users entirely.
Automatic LWW simplifies implementation but can silently lose creative work. Always provide accessible history and an explicit recovery/compare UI; instrument conflict rates and user recovery actions.

Connections

This topic naturally pivots into distributed consistency models (causal vs eventual), CRDT/OT research for collaborative systems, and storage/indexing topics such as content-addressable stores and Merkle trees. Interviewers may also ask about operational concerns: observability, metrics for sync health, and bandwidth-optimized protocols.