#35 Object Storage/CDNs
Photo Sharing (Google Photos)
Store every photo a person ever takes, show their library instantly on any device, and never lose one.
What is being asked
Design a photo service: phones back up photos automatically, users browse a timeline, search by date and content, and share albums.
Requirements
Functional
- Upload from mobile in the background; browse by date; albums and sharing.
- Thumbnails and several display sizes; search.
Non-functional
- Durability above everything: these are memories.
- Billions of objects; storage cost dominates.
- Fast scrolling through a timeline of thousands of thumbnails.
Design
- The client hashes each photo, asks the server whether it already has it, and uploads missing ones in resumable chunks directly to object storage.
- A metadata row records owner, capture time, dimensions and the storage key.
- An upload event triggers asynchronous processing: generate thumbnails and screen-sized versions, read EXIF data, run image labelling for search.
- The timeline is a query on metadata by user and capture time, returning thumbnail URLs served from a CDN.
Key decisions and trade-offs
- Originals are immutable; everything else is derived. Edits are stored as instructions or new versions, so thumbnails can always be rebuilt.
- Storage tiers. Recent photos sit on fast storage; older ones move to cheaper classes, since most photos are never opened again after the first weeks.
- Erasure coding across sites gives very high durability for less than three full copies.
- Private by default. Shared links carry signed, expiring URLs; a CDN must not serve a private photo to someone who guesses a URL.
Follow-up questions
- How do you sync deletions without a bug wiping a library?
- How would you find duplicates and near-duplicates?
- How do you scroll smoothly through 100,000 photos?
- What changes for video?