Bird
Raised Fist0

CDN for Video Streaming - Adaptive Bitrate and HLS Segment Delivery

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/8
Client Device

Sends DNS query

Client requests IP for video streaming domain

Protocol:DNS
BeforeClient knows video domain name only
AfterClient has Edge CDN IP address
DNS Layer

Resolves domain to Edge CDN IP

DNS returns IP address of nearest Edge CDN node

Protocol:DNS
BeforeDNS has domain-to-IP mapping
AfterDNS responds with Edge CDN IP to client
Client Device

Requests HLS manifest

Client sends HTTPS request to Edge CDN for manifest

Protocol:HTTPS
BeforeClient has Edge CDN IP
AfterClient awaits manifest response
Edge CDN Node

Checks cache for manifest

If manifest not cached, forwards request to Load Balancer

Protocol:HTTPS
BeforeManifest may or may not be cached
AfterManifest request forwarded to Load Balancer if cache miss
Load Balancer

Routes manifest request

Sends request to Manifest Generation Service

Protocol:HTTP
BeforeLoad Balancer receives manifest request
AfterManifest Generation Service receives request
Manifest Generation Service

Generates HLS manifest

Fetches segment metadata from Transcoding Service

Protocol:HTTP
BeforeManifest Generation Service has request but no metadata
AfterManifest generated with adaptive bitrate info
Transcoding Service

Provides segment metadata

Returns available bitrate segments info

Protocol:HTTP
BeforeTranscoding Service has transcoded segments stored
AfterMetadata sent to Manifest Generation Service
Edge CDN Node

Serves manifest and segments

Caches and delivers manifest and video segments to client

Protocol:HTTPS
BeforeEdge CDN has manifest and segments cached or fetches from Origin
AfterClient receives manifest and video segments for playback
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│ Client Device │
└───────┬───────┘
        │ HTTPS Request (DNS Lookup)
        ▼
┌───────────────┐
│   DNS Layer   │
└───────┬───────┘
        │ DNS Response (Edge CDN IP)
        ▼
┌───────────────┐
│ Edge CDN Node │
│  (CloudFront) │
└───────┬───────┘
        │ HTTPS Request (Manifest or Segment)
        ▼
┌───────────────┐
│ Load Balancer │
│  (ELB/NGINX) │
└───────┬───────┘
        │ HTTP Request (Manifest)
        ▼
┌───────────────────────────┐
│ Manifest Generation Svc   │
└───────┬───────────────────┘
        │ Fetches Transcoded Segments Metadata
        ▼
┌───────────────────┐
│ Transcoding Svc   │
│  (MediaConvert)   │
└───────┬───────────┘
        │ Stores Segments
        ▼
┌───────────────────┐
│ Origin Storage    │
│ (S3/Cloud Storage)│
└───────────────────┘
Design Rationale

This architecture shows a vertical flow from client DNS resolution to video segment delivery. The client first resolves the video domain via the DNS Layer, which returns the nearest Edge CDN Node IP. The client then requests the HLS manifest from the Edge CDN. If the manifest is not cached, the Edge CDN forwards the request through a Load Balancer to the Manifest Generation Service. This service queries the Transcoding Service for available bitrate segments metadata. The Transcoding Service stores multiple bitrate versions of video segments in Origin Storage. The manifest includes adaptive bitrate info enabling the client to switch streams based on network conditions. The Edge CDN caches manifests and segments to reduce origin load and latency, delivering smooth adaptive streaming to the client.

Primary Focus

✓

Practice

(1/5)
1. In a cache stampede prevention system, at Step 4 the Cache Rebuilder checks if a distributed lock is held before regenerating the cache. What happens if the lock is already held by another process?
easy
A. The Cache Rebuilder immediately regenerates the cache anyway, risking duplicate work
B. The Cache Rebuilder waits or returns stale data until the lock is released
C. The Cache Rebuilder deletes the cache key to force a fresh fetch next time
D. The Cache Rebuilder escalates the request to the backend synchronously

Solution

  1. Step 1: Trace Cache Rebuilder behavior at Step 4

    If the distributed lock is held, another process is regenerating the cache.

  2. Step 2: Understand correct handling

    The Cache Rebuilder waits or serves stale data to avoid duplicate regeneration and backend overload.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Waiting or serving stale data prevents duplicate cache rebuilds [check]
Hint: Lock held -> wait or serve stale, no duplicate rebuilds [OK]
Common Mistakes:
2. A distributed system requires a lock mechanism that ensures mutual exclusion across multiple Redis instances with minimal risk of deadlocks. Which component or approach best handles this requirement?
easy
A. Implement Redlock algorithm coordinating locks across multiple Redis masters
B. Use a relational database row lock with distributed transactions
C. Use a single Redis instance with SETNX and expire for locking
D. Use a centralized ZooKeeper lock service for distributed locking

Solution

  1. Step 1: Understand distributed lock requirements

    Single Redis instance with SETNX risks single point of failure and split-brain issues.

  2. Step 2: Evaluate Redlock's multi-instance coordination

    Redlock uses multiple Redis masters to reduce risk of deadlocks and ensure safety under partial failures.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Redlock coordinates multiple Redis masters for safer distributed locks [check]
Hint: Multiple Redis masters coordinated -> safer distributed locks [check]
Common Mistakes:
3. For internal service communication requiring bidirectional streaming with mobile clients that have intermittent connectivity, which approach is best?
medium
A. Use gRPC bidirectional streaming directly for real-time updates
B. Use gRPC unary calls with client-side polling and exponential backoff
C. Use WebSockets with JSON payloads for flexible streaming
D. Use REST long polling to simulate streaming behavior

Solution

  1. Step 1: Analyze client connectivity constraints

    Mobile clients often have intermittent connectivity and poor support for HTTP/2 streaming.

  2. Step 2: Evaluate streaming options

    Direct gRPC streaming (A) is unreliable on mobile. WebSockets (C) add complexity and JSON is less efficient. REST long polling (D) is less efficient and higher latency. Unary calls with polling and backoff (B) handle intermittent connectivity gracefully.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Mobile intermittent -> unary calls + polling with backoff [check]
Hint: Mobile clients -> unary calls + polling, not streaming [check]
Common Mistakes:
4. For a globally distributed database that must minimize read latency during network partitions, which architecture is the best trade-off according to PACELC?
medium
A. Use synchronous replication with strong consistency guarantees
B. Use a quorum-based protocol for both reads and writes
C. Use a single primary data center with read-only replicas elsewhere
D. Use eventual consistency with asynchronous replication and local reads

Solution

  1. Step 1: Analyze PACELC trade-offs for read latency during partitions

    Minimizing read latency favors local reads and asynchronous replication despite weaker consistency.

  2. Step 2: Evaluate architectures

    Synchronous replication (A) and quorum (D) increase latency; single primary (C) risks unavailability if primary is unreachable.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Eventual consistency + async replication -> low read latency under partition [check]
Hint: Eventual consistency beats sync replication for latency under partition [check]
Common Mistakes:
5. Without a rate limiter in place, what exactly happens when a sudden traffic spike occurs on a backend service?
medium
A. The backend service crashes or becomes unresponsive, causing client requests to time out or fail
B. The backend service rejects requests gracefully with error codes indicating overload
C. The backend service automatically scales up instantly to handle the spike
D. The backend service queues all requests, causing increased latency but no failures

Solution

  1. Step 1: Understand backend behavior without rate limiting

    Without rate limiting, traffic spikes overwhelm backend, causing resource exhaustion and crashes or unresponsiveness.

  2. Step 2: Eliminate incorrect failure modes

    Automatic instant scaling (C) is unrealistic; graceful rejection (D) requires rate limiting; queuing all requests (A) leads to resource exhaustion and eventual failure.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Spike without limiter -> backend crash or unresponsiveness [check]
Hint: No limiter -> spike crashes backend, causing timeouts [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