Design a Photo Library for an iOS App: Thumbnail Grid, Caching, Uploads and Sync

Design a photo library for an iOS app. The report gives only the name of the problem, so its scope is open. A typical scope, to confirm with the interviewer: users browse all of their photos in a scrolling grid of thumbnails, newest first; open a photo full screen and zoom into it; and add photos from the device, which are uploaded so that the library looks the same on every device the user signs in to. Because the round was part of an iOS loop, expect the client side (image loading, caching, local storage and uploads) to carry much of the discussion, and ask how much of the backend to cover. ```hint Size every image for its job Compare how many pixels a grid cell actually needs with the pixels in an original photo, and decide where the smaller versions come from. ``` ```hint Design for an unreliable network Ask what the grid can show before any network response arrives, and what must survive if the app is suspended or killed in the middle of an upload. ``` ### Clarifying Questions - Are the photos the device's own library, photos stored on our servers, or both, with automatic backup from the device? - Is the backend in scope, or should the design focus on the iOS client against an API you define? - Which features are required: grid browsing, full-screen viewing and zoom, upload, delete, albums, search, sharing, video? - How large can one library get, and must browsing work offline? - Must the library stay in sync across several devices, and how quickly should a change on one appear on another? ### What a Strong Answer Covers - Scope agreed first: whose photos, which features, how much backend, and the expected library size - A client architecture with clear layers: UI, local store, image pipeline, sync and upload components - An image pipeline with renditions sized for each use, off-main-thread decoding and downsampling, memory and disk caches, prefetching and cancellation, and correct behavior under cell reuse - Metadata stored locally and kept current with incremental sync, so the grid opens instantly and works offline - A durable upload path: persistent jobs, background transfers, retries and deduplication, with visible upload state - The APIs and, if in scope, the backend storage, rendition generation and CDN delivery - Memory and performance limits, permissions and privacy, failure handling, and the metrics that show the design works ### Follow-up Questions - The user drags the scroll indicator from today to five years ago. How do you keep the grid responsive? - The app is killed halfway through uploading 300 photos. What happens on the next launch, and what does the user see? - A photo is deleted on another device while this device is offline, and the user marked it as a favorite here in the meantime. How does this device find out, and what happens to the edit? - Memory warnings and terminations appear while users scroll quickly through large libraries. Where do you look first?