Design Desktop Sync Client - System Design | WinJob

Problem Statement: The Desktop Sync Client

The desktop sync client is a long-lived OS process that makes a cloud namespace feel like a local folder. Interviewers probe whether you treat sync as a state machine (journal → plan → transfer → commit → reconcile) rather than a cron job that uploads files. Dropbox, Google Drive, and OneDrive all ship thick clients because browsers cannot watch arbitrary paths, throttle on battery, or survive sleep/resume without losing ordering guarantees.

Design focus: Separate local truth (journal + hydrated files) from cloud truth (revision graph). The client never claims 'synced' until the server acknowledges a cursor advance that matches applied local ops.

Operational metrics for this slice

Cursor lag p95 < 30s
Crash recovery < 5s
False sync icon 0%

Client implementation notes (sec-001)

Persist journal rows before opening upload sockets; crash mid-flight must replay safely.
Treat server cursor advance as the only moment peers may observe your changes.
Scope HAVE/dedup lookups to the authenticated namespace—never leak cross-tenant hash existence.
On metered networks, shed prefetch and parallel downloads before delaying user-initiated saves.
Surface conflict forks in filename, not silent overwrites, when server_rev diverges during offline edits.

Failure modes interviewers probe

Watcher missed events after sleep: run periodic subtree checksum scan with rate limit.
SQLite locked: single-writer thread dispatches network callbacks onto engine queue.
Clock skew: use server timestamps for conflict ordering, not laptop RTC.
Disk full: pause engine, pin UX banner, never delete user files automatically.

Deep dive unique to Problem Statement: The Desktop Sync Client

When separate local truth (journal + hydrated files) from cloud truth (revision graph). the client never claims 'synced' until the server acknowledges a cursor advance that matches applied local ops., the desktop agent still maintains monotonic applied_seq even if cloud control plane shards metadata by namespace_id. Desktop sync clients at Dropbox/Google/OneDrive scale batch small files but must not starve interactive saves—priority queue inverts typical FIFO upload fairness.

javaOne Dark Pro

1 public final class DesktopSyncsec001Guard {
2   public boolean mayAdvance(String deviceId, long localSeq, long serverRev) {
3     if (localSeq < 0 || serverRev < 0) return false;
4     return journalAcked(deviceId, localSeq) && serverRevMonotonic(deviceId, serverRev);
5   }
6 }

pythonOne Dark Pro

1 def plan_need_have(local_hashes: set[str], bloom) -> list[str]:
2     """sec-001: compute NEED blocks before opening upload sockets."""
3     need = []
4     for h in local_hashes:
5         if h not in bloom:
6             need.append(h)
7     return need

typescriptOne Dark Pro

1 export interface ClientCursor {
2   namespaceId: string;
3   serverRev: string;
4   appliedSeq: number;
5   lens: "sec-001";
6 }

Why interviewers care

Desktop Sync Client interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

Interview checkpoint

Name one failure story for Problem Statement: The Desktop Sync Client that proves you understand real outages, not happy-path diagrams.

Key Highlights

•Separate **local truth** (journal + hydrated files) from **cloud truth** (revision graph). The client never claims 'sync.
•sec-001: prioritize journal durability before upload parallelism.
•Under load, shed prefetch before delaying user saves in Problem Statement: The Desktop Sync Client.

1	public final class DesktopSyncsec001Guard {
2	public boolean mayAdvance(String deviceId, long localSeq, long serverRev) {
3	if (localSeq < 0 \|\| serverRev < 0) return false;
4	return journalAcked(deviceId, localSeq) && serverRevMonotonic(deviceId, serverRev);
5	}
6	}

1	def plan_need_have(local_hashes: set[str], bloom) -> list[str]:
2	"""sec-001: compute NEED blocks before opening upload sockets."""
3	need = []
4	for h in local_hashes:
5	if h not in bloom:
6	need.append(h)
7	return need

1	export interface ClientCursor {
2	namespaceId: string;
3	serverRev: string;
4	appliedSeq: number;
5	lens: "sec-001";
6	}