Design a Podcast Publishing System That Delivers New Episodes to Followers

Design a podcast publishing system. Creators publish episodes of their shows; listeners follow shows and expect to see new episodes from the shows they follow. The core of the problem is getting each newly published episode in front of the followers of its show. ### Clarifying Questions - How many creators, shows and listeners are there, how many episodes are published per day, and how uneven is the number of followers per show? - How soon after publishing must an episode appear for its followers? - Is the listener's main view one feed across all followed shows, a per-show episode list, or both, and in what order? - Does the platform store and serve the audio itself? Do listeners stream, download, or both? - Are push notifications for new episodes in scope? ### Part 1 — Publishing an episode Design the path from a creator uploading an episode's audio and details to the episode being available to listeners. ```hint Large files and small records travel differently The audio file and the episode's metadata differ hugely in size and access pattern. Think about where each one lives, and in what order they become visible. ``` #### What This Part Should Cover - The upload flow and where the audio is stored and served from - Processing after upload, and the states an episode moves through - The episode data model and the creator-facing APIs - Making "published" reliable: the episode becomes visible, and downstream work is triggered, exactly when its data is committed ### Part 2 — Delivering new episodes to followers Design how each listener gets a feed of new episodes from the shows they follow. Walk through the main ways to build that feed and compare them. ```hint Who pays: the publisher or the reader? For each approach, work out how much work happens when an episode is published and how much happens when a listener opens the app. ``` #### What This Part Should Cover - The feed data model and the listener-facing API, including pagination and ordering - Work done at publish time versus at read time, with rough numbers - Caching, and keeping feed reads fast - Idempotency and retries in whatever runs asynchronously ### Part 3 — Shows with very different audience sizes Most shows have a modest number of followers, while a few have millions. How does your design serve both well, without the largest shows hurting everyone else? ```hint Run the numbers for the biggest show Estimate what your Part 2 design does in the minutes after a show with millions of followers publishes, and find where the cost concentrates. ``` #### What This Part Should Cover - How the design treats small and very large shows, and how a show is classified - What the read path does to combine them - Followers who rarely open the app - Notifications or other per-follower work for very large shows ### What a Strong Answer Covers - Requirements and capacity estimates that drive the later decisions - A publish path with durable storage, processing states and a reliable publish event - A comparison of publish-time and read-time feed construction, supported by numbers - A design that holds up under a highly uneven follower distribution - Failure handling (retries, idempotency, lagging workers) and observability, especially the delay from publish to appearing in feeds ### Follow-up Questions - A creator deletes an episode a few minutes after publishing it. How does it disappear from feeds and from playback? - A listener follows a new show. When and how do that show's recent episodes appear in their feed? - How would you support scheduling an episode to go live at a future time? - How do you send new-episode push notifications for a show with millions of followers without overloading your backend or the notification provider?