Requirements

Functional Requirements:

List the key functional requirements for the system (Ask the AI for hints if stuck)...

• Users should be able to upload and distribute their podcasts.
• Users should be able to browse broadcasts and listen to any.
• Creators should be able to easily see the performance trends and analytics of their podcasts.
• Users should be able to subscribe to any podcast shows, and get notified of new episodes.
• Users should be able to search podcasts by keyword, category etc.
• Users should be able to playback the podcasts in low latency.

Non-Functional Requirements:

List the key non-functional requirements (performance, scalability, reliability, etc.)...

• The podcast browsing can be eventually consistent. An uploaded podcast may not be available to everyone immediately.
• The p99 latency for initiating the upload and sharing podcasts should be less than 200ms, while the p99 latency for viewing/browsing podcasts should be less than 100ms. The p99 latency for time to first audio should be less than 100ms.
• The system should be available 99.99% of time.
• The system should be easily scalable to more users.

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

Assuming 100 million DAU, and on average, each user views and listens to broadcasts 5 times a day, and uploads/shares 1 podcast. also assume peak read QPS is twice of average QPS.

The peak write QPS = 100 million DAU * 1 write per day / 100k seconds per day * 2 = 2k

The peak read QPS = 10k

On storage side, we need to store user metadata, podcast metadata and podcast contents.

For podcast, given we will have 100 million new podcasts per day, and each podcast needs around 2kb for metadata storage, and 50MB for the actual audio in different audio qualities, on each day, we will need additional:

100 million * 2kb = 200GB of metadata storage

and 100 million * 50MB = 5PB of media storage

For data that hasn't been accessed for 1 year, we will put them in cold storage.

On network bandwidth side, assuming at peak, 40% of DAU will be concurrent and listen to podcasts. And each second, 1MB of data is transferred for each user.

The network bandwidth needed is:

40 million * 1MB = 40TB per second

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

For users to publish a podcast:

POST v1/publish_podcast {

user_id: UUID,

publish_time: Timestamp,

podcast_category: String,

podcast_name: String,

podcast_description: String,

podcast_metadata: String,

channel_id: UUID

}

This returns a secured link for uploading the data to CDN to user.

For users to share a podcast:

POST v1/share_podcast {

user_id: UUID,

podcast_id: UUID,

audience_groups: String

}

For users to view details of a podcast:

GET v1/view_podcast {

user_id: UUID,

podcast_id: UUID

}

For users to stream a podcast for playback:

GET v1/playback_podcast {

user_id: UUID,

podcast_id: UUID

}

This returns a signed URL to listen to podcasts from CDN.

For users to subscribe to a podcast channel:

POST v1/subscribe_channel {

user_id: UUID,

channel_id: UUID

}

For content creators to create a channel:

POST v1/create_channel {

user_id: UUID,

created_at: Timestamp,

broadcast_ids: List,

channel_name: String,

channel_description: String,

channel_metadata: String

}

For users to search for podcasts:

GET v1/search_broadcast {

user_id: UUID,

search_keyword: String,

filters: List

}

For users to browse broadcast feed:

GET v1/browse_podcast_feed {

user_id: UUID

}

For content creators to read podcast analytics:

GET v1/view_podcast_trends {

user_id: UUID,

podcast_id: UUID

}

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

In this design, we have a write path and a read path. For both paths, all requests first go through load balancers, and then an API gateway. Load balancers distribute traffic using consistent hashing, while API gateway enforces authorization, authentication and rate limiting.

On the write path, here's a sequence of events to upload/share a broadcast:

1. User gets authenticated from identity service, and identified as an eligible content creator.
2. User initiates an audio upload, and gets back a secure S3 link for uploading.
3. User uploads the audio to S3, which also gets cached at CDN levels in latter reads.
4. Upon upload completion, we trigger a pipeline that does a sequence of content moderation, audio chucking and audio transcoding.
5. After the pipeline finishes, we trigger metadata update, which writes the new podcast/channel metadata to the corresponding databases.
6. Once the metadata update finishes, we trigger events on Kafka queue, and return upload success to the user.
7. For the Kafka events, there are 2 consumer groups. First is index writer, which ingests the new channel/podcast added, and write their metadata to ElasticSearch index cluster, used for searches. Search as a feature is inherently an approximate result, so it's okay for it to
8. The second consumer group is notification service, it queries the subscribers of the channel from redis, and if not available, from underlying database. Then sends notifications to all the relevant clients, alerting them of new podcast/channel updates. Noticeably, there is a fanout here. A hot channel could have millions of subscribers. We cache the subscribers of channels in redis cache cluster. And in the actual fanout requests, the notification service could also leverage Kafka to send all the requests.

On the read path:

1. For viewing channel subscriptions of a user, we query redis. If not available, we query the underlying database.
2. For browsing podcast/channel feeds, we query redis. If not available, we query the underlying database.
3. For search by name/category/author etc., we send a search query to ElasticSearch cluster.
4. For playback of actual audio, we query the audio file from CDN, and download chucks of it for smooth playback. If not available, we query the data from S3.
5. For any playback events, like "starting to listen", "listen for X seconds" etc, we trigger an event on Kafka. The consumer is Flink ETL, which consumes and aggregates the events, and writes to a downstreams OLAP.
6. For content owner to view their channel/podcast trend/analysis, we query the analytics database to generate reports.

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

In this design, there are several contents we need to store:

1. The podcast metadata
2. The channel metadata
3. The channel subscriptions metadata
4. User identity metadata
5. The actual podcast audio
6. The analytic events
7. The podcast/channel metadata for search

For the podcast/channel/channel subscription/user identity metadata, we want to use a relational database. The benefits are:

1. Strong ACID guarantees
2. The data can be easily represented relational data models, supporting complex join queries if needed

The tradeoffs are:

1. Not as easily scalable as noSQL databases
2. The schema is not flexible

The tradeoffs are acceptable in our use case.

Here are some sample data schemas:

table users {

user_id: UUID,

user_name: String,

user_email: String,

user_password_hashed: String,

user_type: String,

user_joined_at: Timestamp,

user_metadata: String

}

table podcasts {

podcast_id: UUID,

podcast_name: String,

podcast_description: String,

podcast_uploaded_at: String

podcast_metadata: String

}

table channels {

channel_id: UUID,

channel_name: String,

channel_description: String,

channel_uploaded_at: String

channel_metadata: String

}

table channel_podcast_link {

channel_id: UUID,

podcast_id: UUID,

podcast_added_at: Timestamp

}

table channel_user_subscription {

user_id: UUID,

channel_id: UUID,

user_subscribed_at: Timestamp

}

To speed up read latency, we will use a redis cluster as the caching layer.

We will use a read-aside cache. For writes, we write directly to database and invalidate the corresponding cache entry. For reads, we read from cache. If not available, we fetch latest data from database and populate cache with TTL. The benefits are:

1. We don't need to store all data in cache
2. Read latency is low since we read from cache first
3. Data is durable as we write to database
4. Less implementation complexity as we implement on application layer

The tradeoffs are:

1. We need to ensure high cache hit rate, otherwise read latency becomes terrible
2. Relatively higher write latency since we write to database instead of cache
3. Eventual consistency, given writing to database and invalidating cache entry is not an atomic operation

In the redis cache, we will store following data with TTL:

1. Podcast/channel feed for a user
2. All subscribed users of a channel
3. Metadata information for frequently visited podcasts/channels
4. All subscribed channels of a user

To ensure 99.99% availability and low read latency in case of cache miss, we will create read replicas for database. For any write, we will write to the primary database, which asynchronously propagate to the read replicas. In case of primary failure, any read replica can continue to serve traffic. This is an eventual consistency approach. For any user who has made a recent write, we ensure that their subsequent read traffic is being served by the primary write replica, so they can always see their own writes.

For the actual audio of podcasts, we will use S3 object storage to store the media files, with local CDNs as caching layer.

For the analytics events, we will use an OLAP like snowflake to store the raw events as well as aggregate results for analysis.

For the podcast/channel metadata for searches, we will use an ElasticSearch cluster to store the metadata.

Podcast metadata lives in Postgres, not a NoSQL store, and that's deliberate:

• Scale is modest. At 1M episodes/day × 2KB metadata, that's ~2GB/day → ~730GB/year. The petabyte-scale data is the audio blobs in S3, not the metadata. Row growth of ~365M/year is comfortably in relational-sharding territory — this is not a big-data problem.
• Read/write profile fits. Peak writes are ~2k QPS; traffic is read-dominated and absorbed by Redis + read replicas. Only cache misses touch the DB.
• The data is genuinely relational. Podcasts belong to channels, subscriptions link users to channels. FKs and joins give us integrity that NoSQL pushes into application code.
• Flexibility via JSONB. Semi-structured fields (chapters, transcripts, artwork variants, tags) go in a JSONB column — schema flexibility inside a relational model, with ACID preserved.
• Sharding strategy. Shard by channel_id (consistent hashing) so all episodes of a channel co-locate. The hot "show page" query is a single-shard lookup — no cross-shard joins on the hot path.

Sample backup & recovery:

• Scheduled backups: nightly full pg_basebackup snapshots to S3, retained 30 days.
• Point-in-time recovery: continuous WAL archiving lets us restore to any second in the retention window — this covers bad migrations and accidental deletes, which replica promotion does not.
• Cross-region replication for DR.
• Other stores: Elasticsearch snapshots → S3; S3 with versioning + cross-region replication; Redis is cache-only (rebuildable), no backup.
• Restore drills to verify backups actually work; defined RPO/RTO targets.

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

In this design, there are several contents we need to store:

1. The podcast metadata
2. The channel metadata
3. The channel subscriptions metadata
4. User identity metadata
5. The actual podcast audio
6. The analytic events
7. The podcast/channel metadata for search

For the podcast/channel/channel subscription/user identity metadata, we want to use a relational database. The benefits are:

1. Strong ACID guarantees
2. The data can be easily represented relational data models, supporting complex join queries if needed

The tradeoffs are:

1. Not as easily scalable as noSQL databases
2. The schema is not flexible

The tradeoffs are acceptable in our use case.

Here are some sample data schemas:

table users {

user_id: UUID,

user_name: String,

user_email: String,

user_password_hashed: String,

user_type: String,

user_joined_at: Timestamp,

user_metadata: String

}

table podcasts {

podcast_id: UUID,

podcast_name: String,

podcast_description: String,

podcast_uploaded_at: String

podcast_metadata: String

}

table channels {

channel_id: UUID,

channel_name: String,

channel_description: String,

channel_uploaded_at: String

channel_metadata: String

}

table channel_podcast_link {

channel_id: UUID,

podcast_id: UUID,

podcast_added_at: Timestamp

}

table channel_user_subscription {

user_id: UUID,

channel_id: UUID,

user_subscribed_at: Timestamp

}

To speed up read latency, we will use a redis cluster as the caching layer.

We will use a read-aside cache. For writes, we write directly to database and invalidate the corresponding cache entry. For reads, we read from cache. If not available, we fetch latest data from database and populate cache with TTL. The benefits are:

1. We don't need to store all data in cache
2. Read latency is low since we read from cache first
3. Data is durable as we write to database
4. Less implementation complexity as we implement on application layer

The tradeoffs are:

1. We need to ensure high cache hit rate, otherwise read latency becomes terrible
2. Relatively higher write latency since we write to database instead of cache
3. Eventual consistency, given writing to database and invalidating cache entry is not an atomic operation

In the redis cache, we will store following data with TTL:

1. Podcast/channel feed for a user
2. All subscribed users of a channel
3. Metadata information for frequently visited podcasts/channels
4. All subscribed channels of a user

To ensure 99.99% availability and low read latency in case of cache miss, we will create read replicas for database. For any write, we will write to the primary database, which asynchronously propagate to the read replicas. In case of primary failure, any read replica can continue to serve traffic. This is an eventual consistency approach. For any user who has made a recent write, we ensure that their subsequent read traffic is being served by the primary write replica, so they can always see their own writes.

For the actual audio of podcasts, we will use S3 object storage to store the media files, with local CDNs as caching layer.

For the analytics events, we will use an OLAP like snowflake to store the raw events as well as aggregate results for analysis.

For the podcast/channel metadata for searches, we will use an ElasticSearch cluster to store the metadata.

Podcast metadata lives in Postgres, not a NoSQL store, and that's deliberate:

• Scale is modest. At 1M episodes/day × 2KB metadata, that's ~2GB/day → ~730GB/year. The petabyte-scale data is the audio blobs in S3, not the metadata. Row growth of ~365M/year is comfortably in relational-sharding territory — this is not a big-data problem.
• Read/write profile fits. Peak writes are ~2k QPS; traffic is read-dominated and absorbed by Redis + read replicas. Only cache misses touch the DB.
• The data is genuinely relational. Podcasts belong to channels, subscriptions link users to channels. FKs and joins give us integrity that NoSQL pushes into application code.
• Flexibility via JSONB. Semi-structured fields (chapters, transcripts, artwork variants, tags) go in a JSONB column — schema flexibility inside a relational model, with ACID preserved.
• Sharding strategy. Shard by channel_id (consistent hashing) so all episodes of a channel co-locate. The hot "show page" query is a single-shard lookup — no cross-shard joins on the hot path.

Sample backup & recovery:

• Scheduled backups: nightly full pg_basebackup snapshots to S3, retained 30 days.
• Point-in-time recovery: continuous WAL archiving lets us restore to any second in the retention window — this covers bad migrations and accidental deletes, which replica promotion does not.
• Cross-region replication for DR.
• Other stores: Elasticsearch snapshots → S3; S3 with versioning + cross-region replication; Redis is cache-only (rebuildable), no backup.
• Restore drills to verify backups actually work; defined RPO/RTO targets.

In this design, we have a write path and a read path. For both paths, all requests first go through load balancers, and then an API gateway. Load balancers distribute traffic using consistent hashing, while API gateway enforces authorization, authentication and rate limiting.

On the write path, here's a sequence of events to upload/share a broadcast:

1. User gets authenticated from identity service, and identified as an eligible content creator.
2. User initiates an audio upload, and gets back a secure S3 link for uploading.
3. User uploads the audio to S3, which also gets cached at CDN levels in latter reads.
4. Upon upload completion, we trigger a pipeline that does a sequence of content moderation, audio chucking and audio transcoding.
5. After the pipeline finishes, we trigger metadata update, which writes the new podcast/channel metadata to the corresponding databases.
6. Once the metadata update finishes, we trigger events on Kafka queue, and return upload success to the user.
7. For the Kafka events, there are 2 consumer groups. First is index writer, which ingests the new channel/podcast added, and write their metadata to ElasticSearch index cluster, used for searches. Search as a feature is inherently an approximate result, so it's okay for it to
8. The second consumer group is notification service, it queries the subscribers of the channel from redis, and if not available, from underlying database. Then sends notifications to all the relevant clients, alerting them of new podcast/channel updates. Noticeably, there is a fanout here. A hot channel could have millions of subscribers. We cache the subscribers of channels in redis cache cluster. And in the actual fanout requests, the notification service could also leverage Kafka to send all the requests.

On the read path:

1. For viewing channel subscriptions of a user, we query redis. If not available, we query the underlying database.
2. For browsing podcast/channel feeds, we query redis. If not available, we query the underlying database.
3. For search by name/category/author etc., we send a search query to ElasticSearch cluster.
4. For playback of actual audio, we query the audio file from CDN, and download chucks of it for smooth playback. If not available, we query the data from S3.
5. For any playback events, like "starting to listen", "listen for X seconds" etc, we trigger an event on Kafka. The consumer is Flink ETL, which consumes and aggregates the events, and writes to a downstreams OLAP.
6. For content owner to view their channel/podcast trend/analysis, we query the analytics database to generate reports.

For the CDN/redis reads, if popular cache entries expire, we could end up with a thundering herd.

To mitigate this, we can adopt following approaches:

1. Request coalescing: Requests for the same hot cache key can be coalesced into 1 single request
2. TTL jittering: For different hot cache keys, we use TTL jittering to make sure that they don't expire at the same time
3. Stale-while-revalidate: We serve stale values first while the cache value is being refreshed in the background.