Design a Public Upload and Hosting Service for Playlist Cover Images

Design the backend service that lets a user attach a custom cover image to a playlist and manage it afterwards: upload a new image, replace it, or remove it. Once an image is set, it must be publicly reachable by anyone, so it can appear in the main app, in embedded players that third-party websites place on their pages, in shared links, and in other surfaces outside the product. The service has to fit into the platform's existing services, such as the identity and authentication system and the service that owns playlist data, rather than rebuilding what they already do. After the core design, the interviewer asks two follow-ups: how someone like an auditor would interact with the service, and how upload and processing failures should be handled. ### Constraints and Clarifications - Assume a playlist shows at most one custom image at a time. - Assume the existing playlist service remains the source of truth for who owns a playlist and who may edit it; the image service asks it rather than keeping its own copy of ownership. - Images are served publicly without authentication, so a viewer of an embed never needs to be signed in. - Expected traffic, file-size limits and accepted formats were not given: ask, and state the values you assume. ### Clarifying Questions - Who may change a playlist's image: only the owner, or collaborators on a shared playlist as well? - What should happen to a publicly reachable image when its playlist is made private or deleted? - Which upload formats and maximum file size should be accepted, and which display sizes do the app, embeds and other surfaces need? - Must an uploaded image pass any content check before it becomes visible to the public? - Roughly how many playlists exist, how often do images change, and how many image views are served per day? ### Part 1 — Core upload, storage and public delivery Describe the APIs, data model and components. Walk through the write path from the moment the user picks a file until the new image is visible everywhere, and the read path that an embed on a third-party page uses to display it. Explain how the service integrates with the existing identity and playlist services, and how other services learn that a playlist's image changed. ```hint Separate the bytes from the pointer Think about where the image bytes should travel and live, versus the small record that says which image a playlist currently shows, and about what makes a public URL safe to cache for a long time. ``` #### What This Part Should Cover - An upload API and authorization flow that keeps large file bytes off the application servers - Storage layout, generated sizes, and the record linking a playlist to its current image - A public read path through a CDN, including how a replacement becomes visible - Integration with the existing ownership and identity services, and notification of downstream consumers ### Part 2 — How an auditor interacts with the service Someone like an auditor needs to review what has happened to playlist images. Explain what they would need to see, how they would get it, and how you would keep their access from becoming a way to change or leak data. ```hint History, not state The current image record only tells you what a playlist shows right now. Ask what an auditor needs that the current state cannot answer. ``` #### Clarifying Questions for this Part - Is the auditor an internal function (compliance, trust and safety) or an external party, and what are they checking: who changed what, policy violations, or data handling? - How long must the history be kept, and must removed images remain retrievable for review? #### What This Part Should Cover - An append-only record of image changes with actor, time, playlist and before and after references - Read-only, scoped access for an auditor role, separate from the user-facing APIs - Retention rules and how removed or replaced images are kept for review - Tamper resistance, and logging of the auditor's own access ### Part 3 — Upload and processing failures Walk through what can fail between the user choosing a file and the processed image going live: interrupted uploads, invalid or corrupt files, a resize job that crashes, a database write that fails after processing succeeded. For each, say what the user sees, what the system retries, and how you keep the playlist from pointing at a broken or half-processed image. ```hint Model the lifecycle Give each upload an explicit state, then ask which transitions can fail, which can be retried safely, and what the playlist shows while a new image is still in flight. ``` #### What This Part Should Cover - An explicit upload lifecycle with states and safe, idempotent retries - Validation of untrusted files and handling of permanently failing inputs - Keeping the previous image live until the new one is fully ready, then switching atomically - Cleanup of abandoned uploads and orphaned objects, plus alerting on failure rates ### What a Strong Answer Covers - Requirements and scale assumptions stated before the design, with the read-heavy traffic recognized - Object storage plus CDN delivery, with long-lived caching made safe by versioned image URLs - Clean boundaries with existing services: ownership checks delegated, change events published - A history model that serves auditors without exposing write paths - Failure handling that never leaves a playlist showing a missing or partial image - Observability for upload success rate, processing latency and CDN errors ### Follow-up Questions - A user replaces an image and the old one is still visible in an embed an hour later. What could cause that, and how does your design prevent it? - How would the design change if images had to pass a policy check before going public? - How would you serve a new size that a client needs but that was never generated for existing images? - What happens if the playlist service is unavailable during an upload, and how should the image service behave?