Adobe Creative Cloud Asset Sync And Conflict Resolution

What's being tested

Interviewers are probing your ability to design a robust, scalable asset sync system that handles offline edits, large binary assets, and deterministic conflict resolution across devices and collaborators. Expect questions that exercise distributed-systems fundamentals (versioning, metadata, anti-entropy), algorithmic choices (CRDT vs. LWW vs. manual merge), and practical engineering tradeoffs (bandwidth, latency, storage costs). Adobe cares because Creative Cloud must preserve user edits, minimize data loss, and deliver responsive UX under concurrent, offline, and high-latency conditions.

Core knowledge

vector clock / version vector — per-replica counters that give a partial order; compare vectors v and w with v ≤ w iff ∀i: v[i] ≤ w[i]; metadata size is O(R) where R = number of replicas.
Last-Writer-Wins (LWW) — simple, low-overhead policy: resolve by highest timestamp (or logical counter); loses concurrent divergent edits but scales well for many binary assets.
CRDT (Conflict-free Replicated Data Type) — convergent algorithms (e.g., RGA, Observed-Remove Set) that ensure eventual convergence without coordination at cost of operation metadata and GC complexity.
Operational Transformation (OT) — transform-based approach for ordered-text/structured edits; lower metadata than some CRDTs but requires a sequencer or careful transform functions.
Content-addressed storage & chunking — store chunks by hash (e.g., SHA-256), support dedupe and delta transfers; useful when files are large (>>10MB) and edits are sparse.
Delta / patch sync — compute binary diffs (rsync/rolling-hash) for large files; server-side patch apply must be idempotent and checksum-verified to avoid corruption.
Tombstones & GC — deletions must be recorded as tombstones to prevent resurrection; garbage collection requires safe epoch or tombstone compaction to reclaim space without losing convergence.
Anti-entropy / reconciliation — use Merkle trees or vector clocks to find differing ranges efficiently; periodic background sync converges replicas without global locks.
Resumable upload & partial reads — implement tus-like resumable protocols and HTTP range requests; crucial for flaky mobile networks and large assets.
Scalability & metadata growth — per-object metadata should be bounded: prefer per-user or per-file vectors (R ~ devices+collaborators, typically <50). For massive collaboration, move to OT/CRDT with per-operation compression.
Security & integrity — verify chunk hashes, sign metadata if client-trust is limited, and encrypt at rest/transport; be mindful of re-ordering attacks if using timestamps.
User-facing policies — automatic merge vs. forced manual resolution: for binary images prefer manual or layered-merge; for structured JSON-like docs choose automatic CRDT merging.
Latency vs. consistency tradeoff — prefer eventual consistency for offline-first UX; reserve strong consistency for critical metadata operations using short-lived leader or consensus only when necessary.

Worked example — "Design an offline-first asset sync for Creative Cloud with conflict resolution"

Frame: first ask scope questions — expected concurrent editors per asset, typical file sizes, offline window length, required offline edits per-device, and acceptable UX for conflicts (auto-merge vs. user choice). Skeleton: (1) Metadata/versioning: attach a per-device logical counter and a small vector clock; (2) Transport & anti-entropy: background gossipping with Merkle tree diffs and resumable chunk uploads; (3) Storage & dedupe: chunked, content-addressed storage in S3 and a metadata DB like Postgres; (4) Conflict policy: pick LWW for simple binary overwrite, but fallback to manual UI when concurrent modifications are detected, or use a CRDT for layered/structured docs. Flag tradeoff: LWW minimizes storage/complexity but silently drops concurrent edits — unacceptable for collaborative PSDs. Close: mention incremental improvements — add delta compression, server-side semantic merge for layered documents, stronger consistency for permission changes, and analytics to tune sync cadence.

A second angle — "Resolve conflicts for layered documents (PSD/Illustrator) where semantic merge is possible"

Same core concept but constraints differ: assets are structured (layers, vectors) so you can represent operations (add layer, change opacity) rather than opaque bytes. This enables an operation-based CRDT or OT per-layer to automatically merge many concurrent edits. Main engineering challenges: define a canonical operation model, ensure ops are commutative/associative or provide transforms, handle large binary blobs inside layers by chunking, and GC old ops once a snapshot is compacted. Tradeoffs: CRDT ensures automatic convergence but increases metadata/operation log sizes and requires careful tombstone/compaction policies; server-assisted semantic merges (best-effort) can reduce metadata but add complexity and potential conflicts that require human resolution.

Common pitfalls

Pitfall: assuming timestamps alone are safe — wall-clock skew and client tampering make naive timestamp LWW unreliable; prefer logical clocks or signed timestamps with server correction.

Pitfall: ignoring tombstone management — treating delete as simple removal leads to "resurrections" when a delayed client syncs an old version; always record deletions and design a GC window.

Pitfall: over-engineering CRDTs for binary assets — CRDTs shine for structured data, but applying them to opaque images increases complexity and storage cost without user-visible benefit; prefer LWW + user-driven merge for opaque binaries.

Connections

Distributed consensus (Raft/Paxos) for metadata that needs strong ordering (e.g., permission changes, canonical merge decisions).
Resumable transfer protocols (tus, HTTP range) and content-addressed storage patterns used by backup/dedupe systems.
Client sync UX patterns (optimistic local commits, conflict UI) and observability (sync telemetry, p99 upload latency).