Design a Photo Album Backend: Upload Consistency, Deduplication and Scaling

Design the backend for a photo album service in the spirit of Google Photos: users upload photos, organize them into albums, and browse their albums and photos from any device. This was the system design round of an entry-level onsite. The interviewer cared about backend infrastructure rather than product features and changed the requirements as the session went on, so adapting the design mattered as much as its first version. Plan to drive the first half yourself (requirements, API, data model and high-level design). In the second half the interviewer leads, with deep dives into the specific problems below. ### Constraints and Clarifications - Focus on storage, consistency, data modeling and scaling. Client UI and product features such as editing or face search are out of scope unless the interviewer adds them. - Requirements will change during the session. Revise the design when they do rather than defending the first version. - No scale figures were given; state your own and size the system from them. ### Clarifying Questions - Can a photo belong to more than one album, and does deleting an album delete its photos? - Which derived versions (thumbnails, screen-sized previews) are needed, and how soon after upload? - Are albums private to their owner, or can they be shared? - What file sizes and formats must be supported: photos only, or video too? - Is deletion permanent, or is there a recoverable trash period? ### Part 1 — Requirements, API and data model Separate the functional from the non-functional requirements, propose the API and the database schema, and sketch the components and request flow for uploading, organizing and viewing photos. ```hint Bytes and facts live apart Think about which data is large and never changes, which is small, relational and queried constantly, and whether they belong in the same store. ``` #### What This Part Should Cover - Functional and non-functional requirements, with priorities stated - An API for upload, album management and paginated browsing - A schema for users, photos, albums and the many-to-many link between photos and albums - Components and the flow of an upload and of an album view ### Part 2 — The upload path 1. Uploading puts the image bytes in blob storage and a record in the metadata database. How do you keep the two consistent? 2. Right after uploading, the user expects to see the photo immediately, even though background processing such as thumbnail generation lags behind. How do you handle that? ```hint No transaction spans both stores Decide which write happens first and what state the photo's record is in between the two writes, then check every point at which the process could stop. ``` ```hint Visible is not the same as finished Separate what the uploader must see now from what can be filled in later, and consider which copy of the database serves the uploader's next read. ``` #### What This Part Should Cover - Write ordering and record states that never expose a photo whose bytes are missing, and never leave bytes that no record points to - Cleanup of abandoned or half-finished uploads - Read-after-write for the uploader despite asynchronous processing and replica lag - How derived versions are produced and surfaced once ready ### Part 3 — Duplicate uploads How do you prevent the same photo from being uploaded more than once by the same user? ```hint Two kinds of duplicate A retried request and the same picture chosen again a week later are different problems; check whether one mechanism handles both. ``` #### Clarifying Questions for this Part - Is a duplicate only the identical file, or also the same picture resized or re-encoded? - Should a duplicate be rejected, or mapped to the existing photo, for example when the user adds it to a second album? #### What This Part Should Cover - Idempotent upload requests - Content-based detection and where the check is enforced - Two concurrent uploads of the same photo ### Part 4 — Choosing and outgrowing the database The candidate chose Postgres for the metadata and was asked to justify it. Why Postgres? At what scale does a relational database become the bottleneck, and what would you do then? ```hint Name the resource Instead of a row count, identify which resource of a single primary runs out first for this workload, and which signals would show it coming. ``` #### What This Part Should Cover - A justification tied to this schema's access patterns and guarantees - Concrete bottleneck signals and the resource behind each - A staged scaling path, including a shard key and what it costs ### What a Strong Answer Covers - Requirements and an API established before components, with the candidate driving the first half - Bytes in blob storage and metadata in a database, with a correct account of how the two stay consistent - A schema and API that support the deep dives instead of being redesigned for each one - Failure handling at every step of an upload, including cleanup - Scaling arguments based on stated estimates, with trade-offs named - Willingness to revise the design when the requirements change ### Follow-up Questions - How would sharing an album with other users change the schema, the access checks and the caching? - A user deletes a photo that appears in three albums. Walk through what happens to its record, its album entries and its stored bytes. - How would you extend the design to video uploads, which are much larger and need transcoding?