Bird
Raised Fist0

CDN for Video Streaming - Adaptive Bitrate and HLS Segment Delivery

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🎯
CDN for Video Streaming - Adaptive Bitrate and HLS Segment Delivery
45 min · senior
senior

You are designing a Content Delivery Network (CDN) optimized for delivering adaptive bitrate video streams using HTTP Live Streaming (HLS) to 50 million daily active users. The system must support encrypted video segments, maintain a P99 latency under 200ms for segment delivery, and handle offline playback scenarios gracefully. The CDN should efficiently serve multiple bitrate variants and scale globally with minimal origin load.

Constraints
  • Encrypted video segments must be delivered securely end-to-end.
  • P99 segment delivery latency must be under 200ms to ensure smooth playback.
  • Support offline playback by enabling segment caching on client devices.
  • Handle 50 million DAU with peak segment request rates exceeding 1 million QPS.
  • Adaptive bitrate switching requires low-latency manifest and segment updates.
📋
Guided Steps
1/5
Step 1
Designing the Segment Storage and Distribution Layer
How will you store and distribute encrypted HLS video segments to meet the scale and latency requirements?
💡 Hint
Consider a globally distributed object store combined with edge caching to reduce origin load and latency.
Key Decision
Use Amazon S3 for origin storage of encrypted HLS segments combined with Amazon CloudFront as the CDN edge cache to achieve global low-latency delivery and automatic cache invalidation.
Interviewer Expectation
Mid-level: Names S3 + CloudFront for storage and CDN. Senior: Explains how CloudFront edge caching reduces origin load and meets P99 < 200ms latency, and why alternatives like self-hosted storage or generic CDNs fail at this scale.
⚠️Common Wrong Answer
Using a single regional storage cluster without edge caching, causing high latency and origin overload during peak traffic.
Step 2
Adaptive Bitrate Manifest and Segment Management
How will you design the system to serve adaptive bitrate manifests and ensure clients can switch bitrates seamlessly?
💡 Hint
Think about how to generate and update HLS master and variant playlists dynamically and cache them efficiently at the edge.
Key Decision
Generate HLS manifests dynamically at the origin using AWS Lambda@Edge for low-latency updates, and cache manifests at CloudFront edges with short TTLs to balance freshness and cache hit ratio.
Interviewer Expectation
Mid-level: Mentions caching manifests at CDN edges. Senior: Explains Lambda@Edge for dynamic manifest generation, TTL tuning for freshness vs cache hit, and why static manifests or long TTLs break adaptive streaming.
⚠️Common Wrong Answer
Serving static manifests with long TTLs causing stale bitrate info and poor user experience during network changes.
Step 3
Secure Delivery of Encrypted Video Segments
How will you ensure secure delivery of encrypted video segments end-to-end while maintaining performance?
💡 Hint
Consider HTTPS delivery, key management, and how to prevent unauthorized access to segments.
Key Decision
Use HTTPS with TLS termination at CloudFront edges, integrate AWS Key Management Service (KMS) for secure key storage, and implement signed URLs with short expiration to restrict segment access.
Interviewer Expectation
Mid-level: Names HTTPS and signed URLs. Senior: Details KMS integration for key rotation, signed URL generation at edge, and why IP whitelisting or token-based auth alone are insufficient at scale.
⚠️Common Wrong Answer
Delivering segments over HTTP or using static keys embedded in clients, leading to security vulnerabilities.
Step 4
Handling Offline Playback and Client Caching
How will the system support offline playback scenarios where clients cache segments locally?
💡 Hint
Think about segment expiration, cache validation, and manifest updates to avoid stale content.
Key Decision
Leverage HTTP cache-control headers with appropriate max-age and must-revalidate directives, combined with client-side storage APIs (e.g., IndexedDB) for offline caching, and manifest versioning to signal updates.
Interviewer Expectation
Mid-level: Mentions cache-control headers and client caching. Senior: Explains manifest versioning to invalidate stale segments, how cache headers balance offline availability vs freshness, and why naive caching breaks adaptive streaming.
⚠️Common Wrong Answer
No cache validation leading to clients playing outdated segments or failing to switch bitrates after network changes.
Step 5
API Design for Client Interaction
Design 3 core API endpoints that clients will use to interact with the CDN for manifest retrieval, segment fetching, and playback reporting.
💡 Hint
Consider RESTful endpoints for manifests and segments, and a telemetry endpoint for playback metrics.
Key Decision
Expose GET /video/{video_id}/manifest.m3u8 for manifests, GET /video/{video_id}/segment_{bitrate}_{seq}.ts for segments, and POST /video/{video_id}/playback_metrics for client telemetry ingestion.
Interviewer Expectation
Mid-level: Defines basic GET endpoints for manifests and segments. Senior: Details RESTful design, URL structure supporting adaptive bitrate, secure POST for metrics with authentication, and how these APIs integrate with CDN caching.
⚠️Common Wrong Answer
Using a single endpoint for all requests causing cache inefficiency and complex client logic.
🔌
API Design Challenge
Sketch 3 core API endpoints for the CDN system that enable clients to request video manifests, fetch video segments, and report playback metrics.
Hints
  • How does the client request and receive the HLS master and variant playlists?
  • How are encrypted video segments requested and served efficiently?
  • How does the client report playback quality or errors back to the CDN or origin?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Use of a globally distributed object store (e.g., Amazon S3) with CDN edge caching (e.g., CloudFront) to meet scale and latency.
  • Dynamic manifest generation with edge compute (e.g., Lambda@Edge) to support adaptive bitrate switching.
  • Secure delivery using HTTPS, signed URLs, and key management (e.g., AWS KMS).
  • API design that cleanly separates manifest, segment, and telemetry endpoints.
Good to Have - 30%
  • Manifest versioning and cache-control strategies for offline playback support.
  • Short TTL caching at CDN edges balancing freshness and cache hit ratio.
  • Integration of client-side caching mechanisms (e.g., IndexedDB) for offline playback.
Bonus - 10%
  • Detailed failure mode analysis for cache staleness and origin overload.
  • Consideration of multi-region origin failover and disaster recovery.
Anti-patterns to Avoid
Serving static manifests with long TTLs causes stale adaptive bitrate info, leading to poor user experience during network changes.
Using a single regional storage cluster without edge caching causes high latency and origin overload during peak traffic.
Delivering segments over HTTP or using static keys embedded in clients leads to security vulnerabilities.
No cache validation leads to clients playing outdated segments or failing to switch bitrates after network changes.
Using a single endpoint for all requests causes cache inefficiency and complex client logic.
✅
Model Answer
▼ Reveal

This design uses Amazon S3 as the origin for encrypted HLS video segments, combined with Amazon CloudFront as the CDN edge cache to achieve global low-latency delivery and reduce origin load. AWS Lambda@Edge dynamically generates adaptive bitrate manifests with short TTL caching to balance freshness and cache hit ratio. Secure delivery is ensured via HTTPS with TLS termination at CDN edges, AWS KMS for key management, and signed URLs with short expiration to restrict access. Offline playback is supported through HTTP cache-control headers, manifest versioning, and client-side caching using IndexedDB. The API design includes RESTful endpoints for manifest retrieval, segment fetching, and playback telemetry ingestion.

Key Decisions
  • Use Amazon S3 as a globally distributed, durable object store for encrypted HLS segments.
  • Leverage Amazon CloudFront as CDN edge cache to reduce origin load and meet P99 latency < 200ms.
  • Implement AWS Lambda@Edge to dynamically generate and update adaptive bitrate manifests with short TTL caching.
  • Secure delivery with HTTPS and TLS termination at CloudFront edges, integrate AWS KMS for key management, and use signed URLs with short expiration for access control.
  • Support offline playback with HTTP cache-control headers, manifest versioning, and client-side caching via IndexedDB.
  • Design RESTful APIs with separate endpoints for manifest retrieval (GET /video/{video_id}/manifest.m3u8), segment fetching (GET /video/{video_id}/segment_{bitrate}_{seq}.ts), and playback metrics reporting (POST /video/{video_id}/playback_metrics) with authentication.
  • Amazon S3 as origin storage for encrypted HLS segments due to its durability and scalability.
  • Amazon CloudFront as CDN edge cache to achieve global low-latency delivery and reduce origin load.
  • AWS Lambda@Edge for dynamic generation and update of adaptive bitrate HLS manifests at edge locations.
  • HTTPS with TLS termination at CDN edges combined with AWS KMS for secure key management and signed URLs for access control.
  • HTTP cache-control headers and manifest versioning to enable offline playback with client-side caching while ensuring content freshness.
  • RESTful API endpoints designed for efficient manifest retrieval, segment fetching, and playback telemetry ingestion.

Practice

(1/5)
1. A system must enforce a maximum number of API calls per user per minute to prevent abuse. Which component in an API Gateway architecture is best suited to handle this requirement?
easy
A. The API Gateway applies rate limiting before routing requests to backend services
B. The backend microservices implement rate limiting individually to distribute load
C. A centralized database tracks request counts and enforces limits synchronously
D. Clients are responsible for self-throttling their request rates

Solution

  1. Step 1: Identify rate limiting responsibility

    The API Gateway is the entry point and can efficiently enforce rate limits before requests reach backend services, preventing overload.

  2. Step 2: Eliminate other options

    The backend microservices implement rate limiting individually to distribute load spreads rate limiting, risking inconsistent enforcement and backend overload. A centralized database tracks request counts and enforces limits synchronously adds latency and complexity by synchronous DB checks. Clients are responsible for self-throttling their request rates trusts clients, which is insecure.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    API Gateway enforces rate limits upfront to protect backend [check]
Hint: Rate limiting belongs at the gateway entry point [check]
Common Mistakes:
2. In a consistent hashing system, at Step 4 the request router receives a key and queries the hash ring to find the responsible shard. What happens if the shard mapped by the hash ring is currently down?
easy
A. The router retries the same shard until it recovers before forwarding the request
B. The router uses the next clockwise shard on the hash ring as a fallback for the key
C. The router returns an error immediately to the client indicating shard unavailability
D. The router hashes the key again with a different hash function to find another shard

Solution

  1. Step 1: Trace request router behavior on shard failure

    Retrying the same shard (The router retries the same shard until it recovers before forwarding the request) blocks requests; returning error (The router returns an error immediately to the client indicating shard unavailability) reduces availability; next clockwise shard (The router uses the next clockwise shard on the hash ring as a fallback for the key) is correct only if the ring is intact and shard failure is handled by virtual nodes.

  2. Step 2: Understand fallback hashing

    Rehashing with a different function (The router hashes the key again with a different hash function to find another shard) is a common fallback to find an alternate shard when the primary is down, ensuring availability without blocking or errors.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Fallback hashing finds alternate shard on failure [check]
Hint: Fallback hashing finds alternate shard if primary is down [OK]
Common Mistakes:
3. A global e-commerce platform wants to route users to the nearest data center to reduce latency. Which component primarily handles this geographic traffic distribution?
easy
A. GeoDNS service that resolves domain names to IPs based on user location
B. A centralized load balancer that routes traffic based on server health checks
C. A CDN that caches static content globally without DNS involvement
D. An application-level proxy that inspects HTTP headers to route requests

Solution

  1. Step 1: Identify GeoDNS role

    GeoDNS resolves DNS queries differently based on the client's geographic location, enabling routing to the nearest data center.

  2. Step 2: Eliminate other options

    A centralized load balancer (A) is a single point and doesn't handle geo-based DNS resolution. CDN (C) caches content but doesn't route DNS queries. Application-level proxy (D) routes after DNS resolution, not at DNS level.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    GeoDNS routes based on client location via DNS resolution [check]
Hint: GeoDNS routes users by location at DNS level [check]
Common Mistakes:
4. Without the asynchronous replication component in a PACELC system prioritizing latency, what exactly breaks during a network partition?
medium
A. Reads return stale data indefinitely without updates
B. Writes block until all replicas acknowledge, causing high latency
C. Local writes succeed but are lost if the node crashes before replication
D. The system automatically switches to a single primary mode

Solution

  1. Step 1: Identify role of asynchronous replication

    It propagates updates to other replicas to keep data fresh despite partitions.

  2. Step 2: Trace failure without async replication

    Without it, replicas do not get updates, so reads return stale data indefinitely.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    No async replication -> stale reads persist during partition [check]
Hint: No async replication -> stale reads never update during partition [check]
Common Mistakes:
5. At 10x scale, which component in the Ticket Server pattern is most likely to become the bottleneck first, and why?
hard
A. Ticket Server, because it handles all block allocations and cannot be sharded easily
B. Clients, because local ID block exhaustion causes frequent server requests
C. Network, because increased traffic saturates bandwidth between clients and server
D. Database storing allocated blocks, because it cannot handle concurrent writes at scale

Solution

  1. Step 1: Identify centralization bottleneck

    The Ticket Server centrally allocates ID blocks and maintains allocation state, limiting horizontal scaling.

  2. Step 2: Compare other components

    Clients scale horizontally; network scales with infrastructure; database load is less critical if Ticket Server caches state.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Ticket Server centralization -> first bottleneck at 10x scale [check]
Hint: Central Ticket Server state limits horizontal scaling first [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard