Adobe Creative Cloud Offline Sync And Conflict Resolution — Tech Interview Concept

What's being tested

Interviewers are probing the candidate's ability to design a robust offline-sync system for large, versioned assets and to reason about deterministic conflict resolution in a distributed, multi-device environment. Expect to demonstrate tradeoffs among optimistic concurrency, locking, state metadata models (timestamps, vector clocks, CRDTs), bandwidth/latency optimizations, and operational concerns (resumable uploads, GC, security) that a backend/server-side engineer must own.

Core knowledge

Optimistic vs pessimistic concurrency — optimistic lets clients make local edits and reconcile later (better UX, harder merges); pessimistic uses server or lease-based locks (simpler correctness, more latency/contention).
Version metadata models — Last-Writer-Wins (LWW) (timestamp-based), Lamport timestamps, vector clocks, and dotted version vectors: vector clocks track causality with O(k) metadata where k = number of causal participants; size/merge cost grows with active device count.
CRDTs vs OT — CRDTs (commutative ops, convergent state) are best for structured documents; OT is for low-latency collaborative text. For large binary files (images, PSD), CRDT/OT are impractical; versioning + semantic merge or user-assisted resolution is used.
File vs chunk-level sync — chunking (4–16MB typical) + content-addressed storage (SHA-256) supports resumable uploads, deduplication, and partial patches; delta-encoding (rsync-like) reduces bandwidth for large-file edits.
Conflict classes — content-conflict (concurrent edits to same bytes), metadata-conflict (rename/move/permission), and structural-conflict (directory moves). Resolve differently: automatic merge, merge service, or create conflict copies/versions.
Deterministic server arbitration — server must be able to deterministically pick a winner when automatic merge chosen: use (1) authoritative device ID + counter, (2) monotonic sequence from server, or (3) application-specific merge policy; never rely only on wall-clock Date.
Tombstones and GC — tombstones prevent resurrection after delete; GC policy: keep tombstones for TTL (e.g., 30 days) or until version-count limit N, then compact. Deleting tombstones requires careful coordination to avoid resurrecting orphan replicas.
Idempotency & exactly-once — use idempotency-key (client-generated) for upload/operation retries; server ops should be idempotent or dedup using operation logs to avoid double-insertions.
Resumability and integrity — chunk upload with per-chunk SHA-256 checksums, server-side reassembly atomically; manifest with chunk list and assembly checksum ensures integrity.
Bandwidth / storage tradeoffs — store full versions for critical assets and deltas for editable ones. For N devices and V versions: metadata cost ~ O(N + V); full-version cost grows linearly with V and asset size — cap V or tier storage.
Clock skew and ordering — wall-clock timestamps are unreliable; prefer logical clocks (Lamport/vector) or server-assigned monotonic sequence numbers when strict ordering is required.
Security & encryption — if end-to-end encryption is needed, server cannot do content-aware merges; design must fall back to versioning/conflict copies or client-side merge helpers.
API & protocol design — design minimal sync protocol: queryChanges(sinceToken), getObject(id, version), uploadChunk, commitManifest, resolveConflict(decision). Keep sinceToken compact (e.g., server sequence + per-collection watermark).

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

Frame it: clarify constraints (file sizes up to multi-GB, some files are mergeable [text/JSON], most are large binaries, intermittent connectivity, multi-device users). Ask about required guarantees: eventual consistency? atomic file commits? conflict visibility to user? Then present skeleton: (1) use optimistic local edits with a background sync engine, (2) chunked uploads with per-chunk SHA-256 and resumable protocol, (3) metadata model combining server-assigned monotonic sequence with per-device vector clock for causality, (4) conflict policies: automatic merge for structured docs, server-side semantic merge service where possible, otherwise create conflict-version and surface to UI. Flag tradeoff: vector clocks capture causality but grow with number of devices — for large user device counts use dotted version vectors or compress older entries. Close by noting operational items: GC policy for versions, metrics to track conflict rate, and if more time, design a background dedupe/compaction job and offline merge helper library for PSD-layer merges.

A second angle — "Support real-time collaborative editing plus offline edits"

Same primitives apply but constraints shift: low-latency live edits require CRDT or OT for structured layers (text, vector shapes). For Creative Cloud: split document into collaborative layers (CRDT-enabled) and non-collaborative binary blobs (images). Use real-time sync (WebSocket/gRPC) for live ops and fall back to the offline sync protocol for disconnected edits. Key decision: partition document model so that CRDTs only govern small, frequently-edited structures; large binary assets remain versioned with chunking and conflict copies. This hybrid reduces metadata overhead and keeps merging semantics clear.

Common pitfalls

Pitfall: Treating wall-clock timestamps as authoritative.
Relying on client Date leads to reordering and lost updates under skew; instead use server monotonic sequence numbers or logical clocks for ordering and causality.

Pitfall: Attempting to auto-merge large binary assets.
Automatic byte-level merges are unsafe for complex asset formats; the tempting "diff-and-patch" approach can corrupt files. Prefer chunked uploads + conflict versioning or format-aware merge services.

Communication mistake — over-prescribing UX: avoid promising "seamless merging for PSD" without clarifying which layers are mergeable. Interviewers look for tradeoff awareness and fallback paths.

Depth mistake — ignoring GC and tombstones: a design that never garbage-collects tombstones or unbounded version histories will fail at scale; include TTL/version caps and a safe compaction protocol.

Connections

Interviewers may pivot to real-time collaboration (CRDT/OT internals), distributed metadata stores (consensus for sequence numbers, e.g., Raft for authoritative server ordering), or secure sync (end-to-end encryption implications on server-side merging).