Netflix — Video Streaming at Global Scale

The back-of-envelope math that decides 'CDN-first' before a single line of code is written.

PLAYBACK (the read path — this is 99% of the traffic)
  180M DAU x 2 hours/day streaming
  avg bitrate ~5 Mbps (mixed SD/HD/4K)
  → per-user data rate  = 5 Mbps
  → concurrent streamers at peak (~20% of DAU during peak hours) = 36M
  → PEAK EGRESS BANDWIDTH = 36M x 5 Mbps ≈ 180 Tbps

  180 Tbps cannot come from one datacenter's uplink — full stop.
  → this number alone FORCES a CDN / edge-cache architecture (Open Connect).
  → 99%+ of this bandwidth must be served from edge caches inside ISPs,
     not from Netflix's own origin. (See Phase 9.5 CDN.)

UPLOAD / TRANSCODE (the write path — tiny by comparison)
  ~1,000 new title-hours ingested per day (originals + partner content)
  each transcoded into ~10 variants (240p...4K, H.264 + AV1)
  average variant size ≈ 1.5 GB/hour of video
  → storage added per day = 1,000 x 10 x 1.5 GB ≈ 15 TB/day
  → over 5 years, with replication (x3) ≈ 82 PB
  → transcode compute: 1,000 hours x 10 variants, at roughly
    1 CPU-hour per output-hour (realistic for modern encoders)
    ≈ 10,000 CPU-hours/day → a modest, autoscaled worker fleet, NOT
    something that needs to happen in real time (this is why it's async).

CATALOG READS
  Browsing generates far more requests than playback starts:
  180M DAU x ~15 catalog/search requests/session ≈ 2.7B requests/day
  ≈ 31k requests/s average, peaked ~5x ≈ 155k/s
  → this is a classic cache-aside (Phase 10.2) + read-replica (Phase 8.1) problem,
    NOT a bandwidth problem — completely different scaling lever from playback.

Every box below gets its own deep-dive with real code further down this page.

The catalog side. Watch-progress deliberately lives in a SEPARATE, strongly-consistent store — see the callout below.

CREATE TABLE titles (
  id            BIGSERIAL PRIMARY KEY,
  name          TEXT NOT NULL,
  type          TEXT NOT NULL CHECK (type IN ('MOVIE','SERIES')),
  release_year  INT,
  metadata_json JSONB NOT NULL DEFAULT '{}',   -- genres, cast, synopsis — flexible, rarely queried by field
  created_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE video_assets (                     -- one per episode/movie cut
  id            BIGSERIAL PRIMARY KEY,
  title_id      BIGINT NOT NULL REFERENCES titles(id),
  duration_secs INT NOT NULL,
  status        TEXT NOT NULL DEFAULT 'PROCESSING'
                CHECK (status IN ('PROCESSING','READY','FAILED')),
  created_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX idx_assets_title ON video_assets(title_id);

CREATE TABLE video_variants (                   -- the output of transcoding — one row per rendition
  id            BIGSERIAL PRIMARY KEY,
  asset_id      BIGINT NOT NULL REFERENCES video_assets(id),
  resolution    TEXT NOT NULL,                  -- '240p','480p','720p','1080p','4K'
  codec         TEXT NOT NULL,                  -- 'h264','av1'
  bitrate_kbps  INT NOT NULL,
  storage_key   TEXT NOT NULL,                  -- content-addressed key into the variant store
  UNIQUE (asset_id, resolution, codec)
);

-- WATCH PROGRESS: separate store, strongly consistent, tiny rows, insane write volume.
-- (Every few seconds of playback pings this. It must NEVER be in the same
--  database as the catalog — completely different access pattern and
--  consistency requirement. This split IS the interview-winning insight.)
CREATE TABLE watch_progress (
  profile_id    BIGINT NOT NULL,
  asset_id      BIGINT NOT NULL,
  position_secs INT NOT NULL,
  updated_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
  PRIMARY KEY (profile_id, asset_id)             -- upsert target; last-write-wins per device is fine here
);

The API surface: the server never touches the video bytes — it only hands out a place to put them.

@RestController
@RequestMapping("/api/ingest")
public class UploadController {
  private final BlobStore blobs;               // same port as Phase 4's File Storage LLD
  private final VideoAssetRepository assets;
  private final ApplicationEventPublisher events;

  public UploadController(BlobStore blobs, VideoAssetRepository assets,
                           ApplicationEventPublisher events) {
    this.blobs = blobs; this.assets = assets; this.events = events;
  }

  public record InitUploadRequest(long titleId, int durationSecs) {}
  public record InitUploadResponse(long assetId, String presignedPutUrl) {}

  @PostMapping("/uploads")
  public InitUploadResponse initUpload(@RequestBody InitUploadRequest req) {
    VideoAsset asset = assets.save(new VideoAsset(req.titleId(), req.durationSecs()));
    String uploadKey = "raw/" + asset.getId() + "/master.mp4";
    String url = blobs.presignedPutUrl(uploadKey, Duration.ofHours(2));
    return new InitUploadResponse(asset.getId(), url);
  }

  // Called by the blob store's webhook once the upload actually completes —
  // the API server was never in the data path for the multi-GB file itself.
  @PostMapping("/uploads/{assetId}/complete")
  public ResponseEntity<Void> completeUpload(@PathVariable long assetId) {
    events.publishEvent(new MasterUploadedEvent(assetId));   // → Kafka, see below
    return ResponseEntity.accepted().build();
  }
}

One consumer, one ladder of outputs. Idempotent by design — see the checklist below the code.

@Component
public class TranscodeWorker {
  private static final List<Rendition> LADDER = List.of(
      new Rendition("240p",  400,  "h264"),
      new Rendition("480p", 1200,  "h264"),
      new Rendition("720p", 3000,  "h264"),
      new Rendition("1080p",6000,  "h264"),
      new Rendition("1080p",4200,  "av1"),      // AV1: ~30% smaller at same quality, costs more CPU to encode
      new Rendition("4K",  16000,  "av1")
  );

  private final VideoAssetRepository assets;
  private final VideoVariantRepository variants;
  private final Transcoder transcoder;          // wraps ffmpeg; swappable for tests
  private final BlobStore blobs;

  public TranscodeWorker(VideoAssetRepository assets, VideoVariantRepository variants,
                          Transcoder transcoder, BlobStore blobs) {
    this.assets = assets; this.variants = variants; this.transcoder = transcoder; this.blobs = blobs;
  }

  @KafkaListener(topics = "master-uploaded", groupId = "transcode-workers")
  public void onMasterUploaded(MasterUploadedEvent event) {
    VideoAsset asset = assets.findById(event.assetId()).orElseThrow();
    byte[] master = blobs.get("raw/" + asset.getId() + "/master.mp4");

    for (Rendition r : LADDER) {
      // IDEMPOTENCY: skip work already done — a redelivered event (Kafka is
      // at-least-once, see Phase 10.13) must not re-encode or double-charge compute.
      if (variants.existsByAssetIdAndResolutionAndCodec(asset.getId(), r.resolution(), r.codec()))
        continue;

      byte[] output = transcoder.encode(master, r.resolution(), r.codec(), r.bitrateKbps());
      String key = "variants/%d/%s-%s.mp4".formatted(asset.getId(), r.resolution(), r.codec());
      blobs.put(key, output);
      variants.save(new VideoVariant(asset.getId(), r.resolution(), r.codec(), r.bitrateKbps(), key));
    }

    if (variants.countByAssetId(asset.getId()) == LADDER.size()) {
      asset.markReady();                        // flips status: PROCESSING -> READY
      assets.save(asset);
    }
  }

  public record Rendition(String resolution, int bitrateKbps, String codec) {}
}
// Failure mode: worker crashes mid-ladder → Kafka redelivers → the existsBy
// check above means only the REMAINING renditions are (re)encoded, not all 6.

Cache-aside with a short TTL — exactly the pattern from Phase 10.2, applied to a real entity.

@Service
public class CatalogService {
  private final TitleRepository titles;
  private final StringRedisTemplate redis;
  private final ObjectMapper json;
  private static final Duration TTL = Duration.ofMinutes(10);

  public CatalogService(TitleRepository titles, StringRedisTemplate redis, ObjectMapper json) {
    this.titles = titles; this.redis = redis; this.json = json;
  }

  public TitleView get(long titleId) {
    String key = "title:" + titleId;
    String cached = redis.opsForValue().get(key);
    if (cached != null) return readJson(cached);            // cache hit — the 99% path

    Title title = titles.findById(titleId).orElseThrow();
    TitleView view = TitleView.from(title);
    redis.opsForValue().set(key, writeJson(view), TTL);      // populate for next reader
    return view;
  }

  // Called when a title's metadata changes (new season, rating update, etc.)
  @CacheEvict                                                 // conceptually — evict, don't write-through
  public void onTitleUpdated(long titleId) {
    redis.delete("title:" + titleId);
    // Deliberately NOT re-populating here: the next reader repopulates it
    // (lazy loading). Re-populating on every write would race with concurrent
    // readers doing the same — see Phase 10.2's "evict on write" rule.
  }

  private TitleView readJson(String s) { try { return json.readValue(s, TitleView.class); } catch (Exception e) { throw new UncheckedIOException((IOException) e); } }
  private String writeJson(TitleView v) { try { return json.writeValueAsString(v); } catch (Exception e) { throw new RuntimeException(e); } }
}

The path that must complete in under 2 seconds — every hop here is on the latency budget.

The two calls in the diagram's 'par' block, fired concurrently — and wrapped for resilience, since Section 8 shows what happens when Progress or Catalog is slow.

@RestController
@RequestMapping("/api/playback")
public class PlaybackController {
  private final ProgressService progress;
  private final CatalogService catalog;
  private final ManifestSigner signer;             // signs CDN URLs with a short-lived token

  public PlaybackController(ProgressService progress, CatalogService catalog, ManifestSigner signer) {
    this.progress = progress; this.catalog = catalog; this.signer = signer;
  }

  public record PlayRequest(long assetId, long profileId, String deviceClass) {}
  public record PlayResponse(String manifestUrl, int resumeAtSecs) {}

  @PostMapping("/play")
  public PlayResponse play(@RequestBody PlayRequest req) {
    // fired concurrently — see Section 8 for the resilience wrapper around each
    CompletableFuture<Integer> resumeAt = CompletableFuture.supplyAsync(
        () -> progress.getPosition(req.profileId(), req.assetId()));
    CompletableFuture<List<VariantView>> variants = CompletableFuture.supplyAsync(
        () -> catalog.variantsFor(req.assetId(), req.deviceClass()));

    CompletableFuture.allOf(resumeAt, variants).join();
    String manifestKey = "manifests/" + req.assetId() + "/master.m3u8";
    String signedUrl = signer.sign(manifestKey, Duration.ofMinutes(6));  // short TTL: URL leaks shouldn't leak forever

    return new PlayResponse(signedUrl, resumeAt.join());
  }

  @PutMapping("/progress")                          // the heartbeat from the sequence diagram
  public ResponseEntity<Void> heartbeat(@RequestBody ProgressUpdate update) {
    progress.upsert(update.profileId(), update.assetId(), update.positionSecs());
    return ResponseEntity.noContent().build();       // fire-and-forget from the client's view
  }
}

Resilience4j: a dedicated thread pool (bulkhead) so a slow recommendation call can never starve playback threads, plus a circuit breaker that stops calling a service that's clearly down.

@Configuration
public class ResilienceConfig {

  @Bean
  public CircuitBreaker recommendationCircuitBreaker() {
    CircuitBreakerConfig config = CircuitBreakerConfig.custom()
        .failureRateThreshold(50)                      // trip after 50% of calls fail
        .waitDurationInOpenState(Duration.ofSeconds(10)) // then stay open (fail fast) for 10s
        .slidingWindowSize(20)
        .build();
    return CircuitBreaker.of("recommendations", config);
  }

  @Bean
  public ThreadPoolBulkhead recommendationBulkhead() {
    ThreadPoolBulkheadConfig config = ThreadPoolBulkheadConfig.custom()
        .maxThreadPoolSize(8)          // recommendations get AT MOST 8 threads, ever
        .coreThreadPoolSize(4)
        .queueCapacity(20)
        .build();
    return ThreadPoolBulkhead.of("recommendations", config);
  }
}

@Service
public class ResilientRecommendationClient {
  private final RecommendationService delegate;
  private final CircuitBreaker breaker;
  private final ThreadPoolBulkhead bulkhead;

  public ResilientRecommendationClient(RecommendationService delegate, CircuitBreaker breaker,
                                        ThreadPoolBulkhead bulkhead) {
    this.delegate = delegate; this.breaker = breaker; this.bulkhead = bulkhead;
  }

  public List<TitleView> recommendationsFor(long profileId) {
    Supplier<CompletionStage<List<TitleView>>> call =
        ThreadPoolBulkhead.decorateSupplier(bulkhead, () -> delegate.recommendationsFor(profileId));
    try {
      return CircuitBreaker.decorateCompletionStage(breaker, call).get()
          .toCompletableFuture().get(300, TimeUnit.MILLISECONDS);   // hard timeout too
    } catch (Exception e) {
      return fallbackRow();          // "Popular on Netflix" — a static, always-available row
    }
  }

  private List<TitleView> fallbackRow() { return CatalogDefaults.POPULAR_ROW; }
}
// Home screen: 8 rows, one of which is recommendations. If that ONE row fails,
// the other 7 (genres, continue-watching, new releases) still render instantly —
// this is what "degrade gracefully" means in code, not just in a slide.

Offline job produces scores; the online path is a pure cache read — the same 'compute ahead of time, serve fast' idea as the transcode pipeline.

@Service
public class RecommendationService {
  private final StringRedisTemplate redis;         // sorted set per profile: titleId -> score

  public RecommendationService(StringRedisTemplate redis) { this.redis = redis; }

  // ONLINE PATH — must be sub-millisecond. No model runs here.
  public List<TitleView> recommendationsFor(long profileId) {
    Set<String> topIds = redis.opsForZSet()
        .reverseRange("rec:" + profileId, 0, 19);    // top 20 by pre-computed score
    return CatalogClient.hydrate(topIds);             // batch-fetch titles (cached, Section 6)
  }

  // OFFLINE PATH — a nightly batch job (Spark/Flink in practice), sketched here as a scheduled task.
  @Scheduled(cron = "0 0 3 * * *")                    // 3 AM, off-peak
  public void recomputeScoresNightly() {
    for (Profile profile : allProfilesBatch()) {
      Map<Long, Double> scores = ScoringModel.score(profile.watchHistory());  // the actual ML lives here
      String key = "rec:" + profile.id();
      redis.delete(key);
      scores.forEach((titleId, score) -> redis.opsForZSet().add(key, titleId.toString(), score));
    }
  }
}