Design a Mobile Photo Backup Service: iCloud / Google Photos

Photo backup is one of the most-used and least-noticed mobile system design problems. iCloud Photos backs up over a trillion photos. The architecture must handle: dedup across millions of users, resumable upload of multi-GB videos over flaky LTE, on-device thumbnails, and tiered storage that pulls full-res from cloud on demand.

Functional requirements

  • Automatically back up photos and videos as they are taken
  • Resume uploads after app kill or network drop
  • Browse photos in chronological grid even when most are stored in cloud
  • Free up local space — keep thumbnails, evict full-res
  • Cross-device: see your iPhone photos on iPad and Mac

Architecture

Three components: local catalog, upload manager, cloud catalog.

Local catalog

SQLite database mirroring the device’s photo library. Each entry: photo ID, taken-at timestamp, EXIF metadata, local file path or “evicted” flag, server ID (after upload), thumbnail blob.

Listen to PHPhotoLibrary change observer (iOS) or MediaStore content provider (Android) for new photos. Insert immediately into the catalog with status pending.

Upload manager

Background-friendly. iOS: URLSession background config; Android: WorkManager with constraints (charging, Wi-Fi).

Steps:

  1. Compute SHA-256 hash of the photo
  2. Check server: does this hash already exist? (Cross-user dedup)
  3. If yes, just record the reference; no upload needed
  4. If no, multipart upload with chunks (8MB or 16MB chunks). Resumable on failure
  5. Server stores the file in tiered storage (hot S3 / cold Glacier) and returns the asset ID

Local space management

User toggles “Optimize iPhone Storage.” When the device runs low on space, evict full-res files for photos that have been backed up. Keep a thumbnail (~50KB) and the original on the cloud. UI is unchanged — taps fetch full-res on demand.

Browsing

The catalog is the source of truth for what photos exist. The grid renders thumbnails from local SQLite. Tap → if full-res is local, display; otherwise stream from cloud with a progress indicator.

Cross-device sync

Each device uploads its own photos. The cloud catalog is the global source of truth. Other devices subscribe to changes (push notifications or pull on app launch) and update their local catalogs.

Encryption

Apple offers Advanced Data Protection — end-to-end encryption with the user’s device key. Server stores ciphertext only. Tradeoff: no recovery if all devices are lost.

Battery and network

  • Default to Wi-Fi only
  • Pause uploads when battery below 20%
  • Compress thumbnails aggressively (HEIF, ~25KB)
  • Background uploads happen when device is charging and on Wi-Fi (Android WorkManager constraints)

Frequently Asked Questions

How does dedup work across users?

Hash-based. Same photo from two users → one underlying blob, two pointers. Privacy concern: hashes leak existence. Real services use convergent encryption or per-user namespaces.

What happens to deleted photos?

Soft delete with a 30-day “Recently Deleted” album. Tombstones synced across devices. After 30 days, hard delete on cloud and on all devices.

How do you handle Live Photos and videos?

Live Photos = JPEG + short MOV pair, uploaded as a single asset. Videos use the same multipart resumable upload but may take much longer; quality of service rules typically defer them to charging + Wi-Fi.

Scroll to Top