System Design Interview
Search your own photos in plain words, inspired by Google Photos and Apple Photos: uploads go to object storage and a CDN, GPU workers label every new photo and turn it into an embedding, and searches like "dog on the beach 2019" are matched by meaning inside each user's private vector index. A teaching design.
See why photos, analysis and search can't share one box.
What was missing: Nothing yet.
Why that's risky: Image bytes swamp the database, uploads wait on the model, and "dog on the beach" misses photos labelled "puppy" and "sea".
What gets added: One server that stores photo bytes in the database, labels each photo during the upload, and searches labels with a text match.
Trade-offs: Simple, but nothing can scale on its own.
Store photos where they belong and label them off the upload path.
What was missing: Photos lived in the database and uploads waited on the vision model.
Why that's risky: Search is still a text match on labels, so it misses anything described in other words.
What gets added: Photos go to object storage behind a CDN; metadata lives in a database partitioned by user. A queue feeds GPU workers that label each new photo in the background.
Trade-offs: A new photo is unsearchable for a few minutes.
Find photos from any description, not just their labels.
What was missing: "Dog on the beach" only matched photos labelled with exactly those words.
Why that's risky: An index shared across users must filter by owner on every query; partitioning by user makes that structural.
What gets added: The vision workers also produce a photo embedding (an image-text model like CLIP puts photos and phrases in the same space). Search turns the phrase into a vector and finds the nearest photos in an index partitioned by user, combined with date and place filters.
Trade-offs: Embeddings cost storage for every photo, but search finally works the way people talk.
Keep endless scrolling off the database.
What was missing: Every scroll of the timeline was a database query.
Why that's risky: A photo deleted on one phone can linger on another for a few seconds.
What gets added: A cache of each user's recent timeline pages and albums; new uploads update the first page.
Trade-offs: Memory for the hottest pages, in exchange for a much lighter database.
Survive holiday upload bursts and remove single points of failure.
What was missing: A holiday burst could swamp everything, and the load balancer, database and index were single points of failure.
Why that's risky: During bursts, analysis lags; photos are safe but not yet searchable.
What gets added: Rate limits per user and device, a second load balancer, replicas for the database and index, a larger GPU pool for upload bursts, and monitoring of the analysis backlog and searches nobody clicked.
Trade-offs: GPUs scale on backlog, not on request rate.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
