Video Streaming System Design Questions
Design principles and patterns for building large-scale, distributed video streaming platforms (e.g., Netflix-like architectures), covering streaming pipelines, content delivery networks (CDNs), transcoding and packaging, content management, metadata services, personalization and recommendations integration, multi-region distribution, caching strategies, fault tolerance, observability, and operational considerations.
MediumSystem Design
125 practiced
As a Solutions Architect, outline an observability strategy for a streaming platform to measure SLOs like startup time, average bitrate, rebuffering rate, and player error rates. Specify which telemetry to collect (metrics, logs, traces), synthetic vs real-user monitoring, tagging/dimensions, and alerting thresholds.
Sample Answer
Requirements & goals:- Measure SLOs: startup time (play-to-ready), average bitrate, rebuffering rate (stall events per play / stall seconds per play), player error rate.- Support RCA across CDN, origin, ABR, player, network, device.- Combine Real User Monitoring (RUM) + Synthetic probes + distributed tracing + service metrics.Telemetry to collect- Metrics (high-cardinality, aggregated): - player.startup_ms (histogram) — record per playback session - player.first_frame_time_ms - player.avg_bitrate_kbps (gauge per session sampled) - player.rebuffer_count (counter per session) - player.rebuffer_seconds (counter) - player.error_count, player.error_codes (counter + tag) - http.segment_latency_ms, http.segment_size_bytes, http.5xx_count - cdn.cache_hit_ratio- Traces: - Distributed traces for session startup and manifest/segment fetches (trace spans: DNS, TCP, TLS, CDN, origin, edge logic, player ABR decision) - Correlate trace id with session id and metrics- Logs: - Player-side structured logs (events: play, pause, error with stack/exception), CDN/origin access logs, transcoder logs - Include correlating IDs for session, user_id (hashed), request_id, trace_idRUM vs Synthetic- RUM (client SDK): primary source for SLOs (real-user distribution, device/browser/network context). Sample all sessions but limit high-cardinality payload (use sampling for traces).- Synthetic probes: geo-distributed scripted playbacks (different bitrates, ABR scenarios) run every 1–5 minutes to check baseline availability/startup and steady-state throughput. Use these to detect regressions before users.Tagging / dimensions- session_id, user_region (continent/country), isp, network_type (wifi/4G/5G), player_version, device_class (mobile/desktop/TV), browser, manifest_id, bitrate_profile, cdn_edge, app_version, ABR_strategy- Use cardinality limits: keep user_id hashed and not indexed; avoid free-form tags.- Use tags for sliceable SLOs and pivoting in dashboards.Aggregation & SLO calculation- Define SLOs on percentiles and ratios: - Startup time SLO: 95th percentile startup_ms < 3s over 30d - Average bitrate SLO: median avg_bitrate_kbps > X per profile; or 90th percentile above threshold - Rebuffering rate SLO: fraction of sessions with rebuffer_count>0 < 1% (or rebuffer_seconds per session < 2s) — use ratio metric - Player error rate SLO: error_sessions / total_sessions < 0.1%- Compute using windowed aggregates (e.g., rolling 7d for alerts, 30d for SLO burn-rate)Alerting thresholds & policy- Three-tier alerts: - P0 (Immediate): Error rate > 0.5% in last 5m OR startup 95p > 6s sustained 5m OR rebuffer rate > 5% — page on-call, runbook. - P1 (Investigate): 95p startup > 4s or error rate > 0.2% over 15m — slack alert. - P2 (Watch): 95p startup > 3s or rebuffer rate trending near SLO over 1h — informational.- Use burn-rate alerts for SLO windows: when error budget burn-rate > 5x expected over 1h -> escalates.- Alerting should include context: recent traces, top-5 dimensions by impact (region/ISP/player_version), synthetic probe results, recent deploys.Correlation & RCA- Link session metrics to traces and logs (session_id + trace_id).- Provide precomputed top-N pivot tables: by player_version, CDN edge, ISP, region.- Automated runbook hints: if segment_latency spikes + CDN cache miss rate high -> CDN edge problem; if trace shows TLS handshake high -> network; if errors concentrated on single player_version -> rollback.Sampling & storage- Full-resolution metrics for key counters; histograms for startup/latency.- Sample traces for RUM (e.g., 5–10% by default) and increase sampling on anomalies.- Retention: metrics 13 months for SLO reporting, traces 30 days, logs 90 days (adjust to cost).Operational practices- Dashboards: SLO summary, top contributors, synthetic vs real-user comparison, latency flame graphs.- SLO review cadence: weekly SLO burn reports, post-deploy synthetic checks, blameless postmortems for P0.- Security & privacy: hash PII, avoid logging raw user identifiers.This strategy ties RUM for accuracy, synthetic for early detection, traces/logs for RCA, and metrics + burn-rate alerts for operational SLO management.
MediumTechnical
71 practiced
Explain eventual consistency for metadata and entitlement services in a streaming platform. Provide examples of where eventual consistency is acceptable (e.g., personalization caches) and where strong or read-after-write consistency is required (e.g., pay-per-view entitlements). Recommend patterns to mitigate risks when using eventual consistency.
Sample Answer
Eventual consistency means updates propagate asynchronously: after a write, different replicas may temporarily return stale data, but given no further writes the system will converge. For a streaming platform this trade-off boosts availability and throughput for high-volume metadata/entitlement operations—but you must pick where stale reads are acceptable.Where eventual consistency is acceptable- Personalization caches (watch-history, “continue watching” widgets): a few seconds/minutes of lag won’t break UX and improves read latency and scalability.- Search/indexing of metadata (new titles appear after indexing window): near-real-time discovery is fine for most catalogs.- Analytics/event pipelines (recommendation model inputs): eventual arrival is acceptable.Where strong or read-after-write consistency is required- Pay-per-view or transactional entitlements (purchase, rental windows): user must see and use immediately after payment — stale reads cause revenue loss or fraud.- License revocations (compliance or account suspension): must be enforced immediately.- Billing/state transitions tied to money or legal obligations.Recommended patterns to mitigate risks when using eventual consistency- Hybrid consistency: use strong consistency (leader/quorum, single-writer) for critical operations and eventual for non-critical paths. E.g., write entitlement to a strongly consistent store, populate caches asynchronously.- Read-after-write for the initiating client: after a write, route that user’s reads to the authoritative node or include the write in a session-local cache until the change is propagated.- Idempotent, versioned updates and causal metadata (vector clocks or monotonic timestamps) to detect and resolve conflicts.- Reliable fan-out with retries and backpressure for propagation; use durable queues and exponential backoff.- Short TTLs and cache invalidation hooks (pub/sub or invalidation events) to reduce window of staleness.- Fallback checks for critical actions: verify entitlement at time of playback start against authoritative store.- Auditing, monitoring, and SLOs: instrument propagation latency, stale-read rates, and set alerts; automate rollbacks or feature-gates if thresholds exceeded.These patterns let you balance latency/scale with correctness: keep money/legal flows strongly consistent and optimize user-visible, non-critical metadata with eventual models while adding safeguards (read-after-write, authoritative checks, invalidations) where needed.
MediumSystem Design
75 practiced
Design a Playback Authorization API that issues signed, time-limited tokens for CDN-served video URLs. Define endpoints, token payload fields (user_id, content_id, expiry, scope, signature), token validation flow at CDN and player, key rotation, and how to handle clock skew and revocation.
Sample Answer
Requirements (clarify): issue short-lived, signed tokens for CDN-served video URLs so only authorized players can playback; support scale, key rotation, revocation, tolerant to clock skew.API endpoints:- POST /auth/token - Input: { user_id, content_id, client_id, scope (playback|preview), requested_ttl } - Output: { token (compact JWT-like), expires_at }- GET /auth/public-keys - Output: current + previous public keys (kid, pubkey, valid_from, valid_to)- POST /auth/revoke - Input: { token_id or user_id or content_id } (admin/auto) - Output: statusToken payload fields (compact JSON signed):- token_id: UUID- user_id: string- content_id: string- scope: string (e.g., "playback", "preview", bitrate restrictions)- iat: issued-at (unix)- exp: expiry (unix)- aud: CDN or client_id- kid: key id- sig: signature (separate JWS compact)Validation flow:1. Player requests token from /auth/token (authenticated client).2. Player requests CDN URL with token as query header: https://cdn/.../video.mp4?token=...3. CDN edge checks token signature using public keys (GET /auth/public-keys cached), verifies kid -> pubkey, validates exp and aud, scope and content_id match requested URL, and token_id not in revocation store (fast cache/Redis).4. If valid, CDN serves; else 401/403.Key rotation:- Use asymmetric keys (private holds in HSM/KMS).- Publish keys with validity windows. Keep previous keys for grace period.- Rotate by creating new key, update /auth/public-keys, set new kid, sign new tokens with new key. CDN caches keys with TTL and falls back to previous keys.Clock skew & TTL:- Allow small skew (±120s) when validating iat/exp; prefer short TTLs (30–300s) depending on UX.- Use server-synchronized time (NTP) and include iat so clients can detect large skews.Revocation:- Support revoke by token_id, user_id, content_id.- Maintain revocation list in low-latency store (Redis) with expiry matching token exp to avoid unbounded growth.- CDN checks revocation cache; for scale, use bloom filter + periodic full sync or push invalidation messages to edges via pub/sub (e.g., CDN edge cache invalidation).Security & performance considerations:- Rate-limit /auth/token and require client authentication (mTLS/OAuth).- Sign tokens with RS256 or EdDSA; keep token size small.- CDN performs validation inline—use optimized crypto libs in edge workers (WASM/Lambda@Edge).- Monitoring: token issuance/revocation metrics, key usage, failed validations.Trade-offs:- Short TTL reduces revocation need but increases token requests and latency.- Asymmetric keys allow CDN validation without private key exposure; HSM adds cost but improves security.
HardTechnical
86 practiced
As the architect integrating personalization and analytics, design controls to ensure GDPR compliance: PII minimization in telemetry, consent capture and propagation, data retention policies, and regional processing constraints. Describe architectural patterns to enforce these controls across services.
Sample Answer
Situation: A global SaaS client needs telemetry-driven personalization while complying with GDPR across regions.Design overview (privacy-by-design):- Centralize privacy controls but enforce at the edge. Key components: Consent & Identity Service, Policy Engine (policy-as-code), Data Classification + Schema Registry, Regional Data Planes, Telemetry Proxy/SDKs, Retention Manager, Audit & Reporting.Controls & patterns:1. PII minimization in telemetry- SDK + Edge Telemetry Proxy: instrumented SDKs perform local redaction/pseudonymization before data leaves the client (hashing, tokenization, noise for analytics). Proxy enforces schema rules from a central Schema Registry that marks fields as PII/sensitive.- Sidecar Pattern: sidecars attached to services validate outgoing events against PII rules and drop/transform sensitive attributes.2. Consent capture & propagation- Consent & Identity Service issues consent tokens (JWT) encoding scope, purposes, timestamp, region. SDKs attach token to telemetry; API Gateway/Message Broker validate tokens via Policy Engine (e.g., OPA) to allow/deny ingestion or apply processing rules.- Consent-change propagation: consent events update real-time filtering rules in SDKs/proxies via config push (gRPC/Config service) and trigger downstream revocation workflows (e.g., delete/pseudonymize past data).3. Data retention policies- Retention Manager stores policy per data-class/purpose/region. Data storage layers (time-series DB, object store, analytics DB) enforce TTLs via lifecycle policies and periodic sweep jobs. Delete requests and right-to-be-forgotten workflows are orchestrated by a GDPR Workflow service that reconciles indexes and triggers physical deletion or cryptographic key destruction for encrypted PII.4. Regional processing constraints- Regional Data Planes (EU, UK, US, APAC): ingress routed by Geo-aware API Gateway; processing and storage pinned to region using infrastructure tags and IAM policies. Cross-region transfer requires explicit consent scope. Use data residency-aware message routing in the event bus.Enforcement patterns across services:- Policy-as-code (OPA) evaluates consent tokens, data-class, and region at API Gateway, Broker, and Storage layer.- Schema Registry + Contract Testing ensures producers don't send PII unexpectedly (CI gates).- Tokenization Service issues reversible or irreversible tokens; keys managed in KMS with key zoning per region.- Audit & Immutable Logs: every access, transformation, deletion logged to tamper-evident store for compliance reporting.- Monitoring & Drift Detection: metrics for policy violations with automated alerts and quarantine pipelines.Trade-offs & mitigations:- Latency from edge checks mitigated by local SDK caching and async pipelines.- Complexity managed with phased rollout: start with SDK-based redaction + central policy engine, then add regional planes.Result: This architecture enforces PII minimization, consent propagation, retention, and regional constraints consistently, auditable end-to-end, and scalable for enterprise deployments.
MediumTechnical
72 practiced
List practical strategies to reduce CDN egress and operational costs for a large streaming provider while preserving user experience. Discuss caching improvements, regional replication, bitrate-ladder optimization, multi-CDN negotiation, origin offload, and storage lifecycle (hot/warm/cold).
Sample Answer
Start with goals and measurable targets: reduce CDN egress cost by X% while keeping key UX KPIs (startup time <2s, rebuffer <1%, quality switches minimal). Then apply layered, measurable controls:Caching improvements- Increase cache hit ratio by tuning TTLs, cache-control headers, and use consistent request URLs (remove query noise). Example: extend TTLs for manifest/playlist to 30–300s and sessions’ non-critical fragments longer where safe.- Use cache-friendly packaging (CMAF + chunked encoding) so small segments are reusable across bitrates and ABR sessions.- Implement edge-side manifest stitching and edge-assembled HLS/CMAF to reduce origin calls.Regional replication & origin placement- Place regional origins (object storage + origin servers) in high-demand regions to avoid cross-region egress. Use geographic routing (DNS/GEO) to prefer nearest origin/CDN POP.- For countries with sustained demand, pre-populate edge caches or deploy regional cache nodes to cut backbone transfer.Bitrate-ladder optimization- Analyze real user telemetry (CR, bandwidth distributions) and prune rarely used renditions. Use a dynamic ladder: fewer renditions at low-view rate profiles, more where revenue/engagement warrants.- Use transcoding profiles with VMAF targets, not fixed bitrates—drop redundant bitrates (e.g., adjacent renditions with <1–2% QoE diff).Multi-CDN negotiation & routing- Use traffic steering: send bulk/static assets to lowest-cost CDN while keeping latency-sensitive endpoints on premium CDN. Implement per-region/per-content routing policies and failover.- Negotiate volume discounts and committed egress tiers based on predictable traffic slices; push cold/off-peak traffic to cheaper egress windows.Origin offload & edge compute- Offload origin by pushing processing to edge: manifest generation, watermarking, DRM token validation, and basic personalization at POPs. Reduces origin hits and egress.- Use long-lived object storage (S3-like) as primary store with CDN as cache; ensure signed URLs so CDN serves directly from storage when cached.Storage lifecycle (hot/warm/cold)- Classify assets by popularity (last 7/30/90 days). Keep hot assets in edge-preloaded caches and in fast storage. Warm in regional replicas with moderate retrieval times; cold in archival (Glacier/Archive) with on-demand restore.- Automate lifecycle transitions with TTLs and popularity thresholds; pre-warm for scheduled live/expected spikes.Trade-offs & metrics- Track cost per stream, cache HIT ratio, origin egress GB, startup/rebuffer rates. Trade lower cost vs slightly higher latency on rare cold restores.- Run A/B tests when pruning ladder or moving content to cheaper CDN to validate QoE impact before wide rollout.Implementation roadmap1. Instrument telemetry and cost attribution per asset/region.2. Pilot dynamic bitrate pruning + cache header tuning in one region.3. Negotiate multi-CDN routing + discounts.4. Roll out origin offload and storage lifecycle policies.This combination preserves UX by using telemetry-driven decisions, edge-first strategies, and contractual negotiation to reduce egress and operational costs.
Unlock Full Question Bank
Get access to hundreds of Video Streaming System Design interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.