Design Cloud Photo Storage and Multi-Device Sync
Design a cloud photo service in the shape of iCloud Photos: a user's library lives in the cloud, every device can upload and download, and a change made on one device — a new photo, an edit, a delete, an album move — shows up on the others.
Assume 200M active users with about three devices each, ~4 new photos per user per day at ~3 MB (so petabytes of new bytes daily), libraries of 10k+ assets, and devices that spend hours or weeks offline. A new photo should appear on the user's other online devices within seconds as a thumbnail; originals may arrive later or on demand.
Cover: the upload path and where an asset atomically comes into existence; the sync protocol between the server and a device that has been offline; the metadata model and how it is partitioned; conflicts between devices (edit vs edit, edit vs delete); failure recovery for interrupted uploads; and what you would measure.
Hints
Hint 1
Separate the planes before anything else: photo bytes go from the device straight to object storage through a resumable upload session; your API tier only handles small metadata records. The asset exists when its metadata commits, which happens after the bytes are durable.
Hint 2
Sync is a per-library ordered change log. Every mutation gets the library's next sequence number; a device stores a cursor and asks for everything after it. A silent push only means 'poll now' — correctness never depends on the push arriving.
Hint 3
Make every client mutation idempotent with a client-generated id, and decide conflict rules per record type: non-destructive edits with a version check, delete-wins with a recoverable tombstone.
Asked at
Sign in to talk to the interviewer — ask what's in scope, what scale to design for, or for a nudge when you're stuck. Conversations save to your account.