Design Cloud Photo Storage and Multi-Device Sync
AppleSoftware Engineer · OnsiteLast updated
Design a scalable cloud photo storage and multi-device synchronization system supporting resilient media uploads, conflict-free sync, and bandwidth-efficient thumbnail and preview generation.
Scenario
Design a cloud media storage service (similar to Apple iCloud Photos) that enables users to securely store photos and videos and keep their photo library synchronized across multiple personal devices (e.g., iPhone, iPad, Mac, and web).
Requirements
Functional Requirements
- Resumable Uploads & Downloads: Upload full-resolution media from any device with support for pause, resume, and background chunking.
- Multi-Device Synchronization: Reflect new photos, edits (crops, filters), metadata changes (favorites, tags), and deletions across all of a user's active devices within seconds.
- Offline Capability & Reconciliation: Allow offline browsing, local edits, and queued uploads that reconcile seamlessly once network connectivity is restored.
- Storage Optimization: Support device-tier storage modes (e.g., keeping only lightweight thumbnails/optimized versions locally while streaming full-resolution originals on demand).
Non-Functional Requirements
- Extreme Durability: Media loss is unacceptable (
99.999999999%durability for raw blobs). - Low Sync Latency: State changes should propagate to online devices in under 5 seconds.
- Bandwidth & Battery Efficiency: Minimize redundant network transfers using delta updates and background push triggers.
- Strong Account Isolation & Security: End-to-end encryption or server-side encryption at rest with strict per-user authorization.
Scale & Assumptions
- 100 million Daily Active Users (DAU).
- Average user uploads 10 photos/day (~1 billion uploads/day, ~12,000 writes/sec average, ~30,000 writes/sec peak).
- Average photo size: 4 MB original, 200 KB preview, 20 KB thumbnail.
- New blob storage: ~4 PB of media added per day.
- Read/browsing traffic is 10x write traffic.
Key Areas to Cover
- API & Media Ingestion: Endpoints for initiating multipart uploads, fetching delta changes, and generating pre-signed upload URLs to bypass application servers for blob data.
- Data Modeling: Schema for photo assets, albums, revisions, and device sync cursors (e.g., logical clocks or monotonic change logs).
- Sync Engine Architecture: How client-side engines and backend services track changes, resolve concurrent conflict scenarios (e.g., edit vs. delete), and handle idempotent replays.
- Asynchronous Processing: Pipeline for generating thumbnails, computing perceptual hashes, extracting EXIF data, and notifying other devices via push services (e.g., APNs).
- Failure Modes & Trade-offs: Handling partial chunk uploads, partitioned network states, and trade-offs between immediate consistency and battery/data conservation.
Hints
Hint 1
Decouple the high-bandwidth media blob transfer (direct to object storage via pre-signed URLs) from the low-latency metadata sync engine.
Hint 2
Model the sync feed as an append-only per-user sequence log so clients can reliably request all mutations occurring after their last known revision cursor.
Hint 3
Handle offline conflicts by distinguishing between asset blob state (immutable content-addressed chunks) and asset metadata (mutable via Last-Write-Wins or vector clocks).
Follow-up questions
- How would you implement photo deduplication across identical uploads to reduce backend storage costs without compromising user privacy?
- If a user deletes a photo on Device A while Device B edits the same photo offline, how should the sync engine reconcile the conflict when Device B reconnects?
- How does your architecture handle push notification delivery limits and silent background sync constraints imposed by mobile operating systems?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.