How the interviewer opens it
“Design a photo storage and sharing platform like Google Photos or Flickr. Users should be able to back up photos from their devices, browse and search their library, and share albums.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- scale
- read:write mix
- media sizes
- devices and uploads
- browsing and search
- album sharing
- latency and processing
- consistency and availability
- durability and deployment
- deletion and other boundaries
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Reliably back up photos from multiple devices and delete photos from the service
- Browse a chronological library, view photos, and download originals
- Search a user's library by capture date, tags, and captions
- Create read-only shared albums and revoke access
Usually out of scope
- Video storage and playback
- Automatic face recognition, object recognition, and semantic search
- Photo editing, collaborative albums, and a social feed
- Billing, subscriptions, and strict storage quotas
- Deleting files from users' devices
- Active multi-region serving and regional disaster recovery
What interviewers probe
- Reliable backup across retries and devices
- An upload spans an unreliable client connection, object storage, and a metadata transaction. A photo must not be acknowledged before it is durable, duplicated by a retry, or left permanently invisible after a partial failure.
- Asynchronous media processing without losing or resurrecting photos
- Original durability, preview readiness, and search visibility happen at different times. Workers can fail, repeat work, process malformed images, or finish after a user has deleted the photo.
- A large, changing library with bounded search staleness
- Users scroll years of photos while devices upload old and new pictures concurrently. Capture order differs from arrival order, and a search index can return deleted or no-longer-visible records.
- Private sharing with useful CDN caching and bounded revocation
- Media benefits from long-lived caching, but album membership and permissions can change. A cached image URL can outlive the permission that originally justified issuing it.
Common mistakes
- Storing image bodies in the metadata database or routing every media byte through application servers.
- Drawing object storage, a queue, and a database without defining upload completion, retry behavior, or repair of partial failures.
- Treating image processing as part of the synchronous durability path.
- Designing automatic AI search before clarifying what search means.
- Ignoring capture-time ordering, stable pagination, or stale search results.
- Using permanent public media URLs and claiming that changing an album ACL revokes them.
The bar by level
- Senior (L5/E5)
- Defines the upload acknowledgment boundary, resumable and idempotent flows, outbox and reconciliation behavior, indexed keyset pagination, and search staleness handling. Explains how CDN delivery remains private and meets the 60-second revocation bound, including deletion during processing.
- Staff (L6+/E6+)
- Can earn full staff credit entirely within the core scope in 45 minutes. Leads a coherent design, states end-to-end durability and access-control invariants, and tests the highest-risk paths against failures spanning storage, metadata, workers, and caches. Uses the estimates to justify partitioning, separate media costs from metadata costs, and choose where complexity is warranted. Depth and prioritization matter more than covering every probe. Regional expansion, content deduplication, or strict quotas can each provide an alternative stretch signal if introduced; they are neither cumulative requirements nor prerequisites for staff credit.