YouTube / Video Streaming — system design by AgileViper46

Latency target is qualitative, not measurable

You say 'low latency video streaming,' but what happens when startup time or rebuffering gets worse in production? Without concrete targets such as video start time, chunk fetch latency, or acceptable buffering rate, it is hard to know whether the system meets the requirement or where to set capacity and alerting thresholds.

Availability target is not translated into service-level expectations

You mention 99.99% availability, but have you considered what that means per user-facing flow? Streaming, upload initiation, upload completion, metadata reads, and likes have very different failure tolerance. Without mapping the availability target to specific APIs or journeys, the number stays aspirational and does not clearly drive operational decisions.

Scalability numbers do not connect cleanly to the stated assumptions

The assumptions say 1B users, 10M DAU, and high-frequency streaming, but the explanation justifies Postgres with 'read QPS + write QPS is < 2000' without showing how that follows from those assumptions. What happens if metadata reads, upload state transitions, and like lookups are materially higher? The risk is under-sizing core paths because the throughput estimate is not defended.

Consistency choice is only justified for counters, not for user-visible like state

Eventual consistency is fine for aggregate counts, but have you considered what happens when a user likes a video and immediately refreshes? The design mentions overwriting by (video_id, user_id), but the NFR discussion does not separate the consistency needs of the per-user liked state from the aggregate counter. If both are eventually consistent, users may see their own action appear lost even if the backend eventually converges.

Relationship between Video and VideoMetadata is unclear

Have you considered whether VideoMetadata is a separate entity or just attributes of Video? Right now both are listed as core entities, but the relationship is not defined. If this is really a 1:1 extension of Video, say so explicitly; otherwise it is hard to reason about ownership and lifecycle.

User-to-Video ownership is not stated

What happens when you need to answer basic domain questions like 'which videos did this user upload' or enforce uploader permissions? The design names Users and Videos, but it never explicitly defines that a User owns or uploads many Videos. That 1:N relationship is part of the core upload flow and should be called out.

Like relationships are only partially defined

You imply Likes are keyed by (video_id, user_id), but the domain relationship should be stated directly: Users like Videos through a Like join entity, giving a many-to-many relationship with one Like per user-video pair. Without making that explicit, it is harder to reason about uniqueness, unlike/retoggle behavior, and how counts derive from source-of-truth records.

Encoding capacity is not sized from the upload volume

You estimated 10K hours of uploads per day and the resulting storage footprint, but what happens when the transcoding backlog grows? Without converting daily upload hours into required parallel encoding throughput, GPU/CPU fleet size, and processing SLA, the system could accept uploads faster than it can make them playable.

CDN origin and cache-hit assumptions are missing

The 2 Tbps peak bandwidth is a good top-line number, but how much of that is expected to be served by the CDN versus pulled from origin? If cache hit rate drops for long-tail content or new uploads, origin bandwidth and blob read capacity can become the real bottleneck. You should size origin egress using an explicit cache-hit assumption.

Replication and multi-region overhead are only applied to stored video

You accounted for 3x replication on encoded video storage, which is good, but have you considered the same overhead for likes data, metadata, Redis memory, and cross-region copies if the 1B-user platform is geographically distributed? At this scale, control-plane storage is smaller than media but still worth sizing so failover and regional expansion are grounded in numbers.

Like API is missing user-facing idempotency and state semantics

Have you considered what happens when the client retries POST /likes/{video-id} because of a timeout or flaky mobile network? Without a clear contract for whether this is 'set my reaction' versus 'append an event', the client cannot know if a retry will double-apply, overwrite, or race with a dislike. You could improve this by making the endpoint explicitly represent the caller's current reaction, for example PUT /videos/{videoId}/like with a body like {"reaction":"like|dislike|none"}, and documenting idempotent retry behavior.

Error model is underspecified for upload and playback edge cases

What does the client see when upload initialization fails, a presigned URL expires mid-upload, the video is still processing, or the video ID does not exist? The explanation mentions a 409-style processing error, but the API contract does not consistently define status codes or error shapes across routes. At this scale, clients need predictable responses such as 404 for missing videos, 409 for not-yet-playable videos, 401/403 for unauthorized actions if applicable, and a structured error body with retry guidance.

Upload flow is not cleanly modeled as an API contract

Have you considered how the client knows when a multipart upload is complete and when encoding should start? POST /videos returns a presigned URL, but PUT /presigendURL is not really your platform API and does not show the completion step back to your service. Without an explicit finalize/complete upload call or callback contract, the client-facing flow is ambiguous. You could improve this by modeling it as create upload session -> upload parts to blob -> complete upload session on your API.

Postgres failover story is too weak for a 99.99% metadata service

Have you considered what happens when the primary Postgres node fails during video upload or metadata updates? The explanation mentions a single replica failover strategy, but the design does not show how failover is detected, how writes are rerouted, or what happens to in-flight metadata mutations. Since every upload and playback bootstrap depends on metadata, this is a key SPOF unless failover is automated and fast.

Redis is on the critical read path without a clear degradation plan under cache loss

What happens if the Redis cluster is unavailable or cold after failover? The explanation says the system falls back to the database, but both metadata reads and like reads would suddenly hit Postgres/Cassandra directly. At 10M DAU, even if average QPS looks manageable, cache loss can create a thundering herd on the backing stores. You could improve this by describing cache warmup, request coalescing, and per-key TTL/jitter to avoid stampedes.

Encoding completion and metadata update flow is underspecified under worker failure

Have you considered what happens if an encoding worker uploads only some renditions or crashes after writing segments but before the processing server updates Postgres? The explanation says workers commit only after completion and are deduped, which is good, but the HLD still leaves open how partial outputs are detected, retried, and cleaned up so clients never see incomplete manifests or stale PROCESSING states.