Skip to content

PATTERN Cited by 1 source

Serverless function for media processing

Intent

Dispatch per-clip / per-sub-segment media-processing work as stateless serverless functions — Docker-packaged workers invoked by an orchestrator to do one unit of work and shut down. Scale by parallelism across many small workers rather than by concentration on a few big ones.

Context

Media processing (inspection, debayer, transcode, deliverable render, VFX plate generation) has a shape that maps cleanly to FaaS:

  • Naturally parallelisable at the clip / sub-segment / frame-range boundary.
  • Each unit of work is bounded in duration (minutes, not hours).
  • No cross-unit state needed — a deliverable render for clip A doesn't depend on the render for clip B.
  • Output is written to durable storage; the worker dies after writing.

Relevant when:

  • Workloads are spiky — quiet days followed by VFX turnovers or finishing pulls requiring thousands of parallel renders.
  • Turnaround matters more than single-worker throughput.
  • Cloud provides a wide CPU pool (see concepts/cpu-only-media-processing) that elastic scaling can tap.

Solution

A four-part runtime checklist for any tool running under this pattern:

  1. Packageable as Serverless Functions in Linux Docker images — fast to launch, fast to shut down, self- contained.
  2. Runs on CPU-only instances — tap the wider cloud compute pool (concepts/cpu-only-media-processing). GPU instances stay reserved for workloads that need them.
  3. Headless invocation via Java / Python / CLI (concepts/headless-api-invocation). No GUI, no interactive session.
  4. Operates statelessly — on failure, terminate and re-launch the worker without recovery steps (concepts/stateless-compute).

Wrap the tool as a per-clip-input serverless function that accepts:

  • Input clip + location.
  • Output location.
  • Processing parameters (frame ranges, color metadata files like AMF, framing decisions like FDL, etc.).

Dispatch one function invocation per clip or per sub-segment of a clip. The orchestrator fan-outs to thousands in parallel when needed, yields capacity back when the queue drains.

Canonical instance — Netflix Cosmos Stratum Functions

Netflix's Cosmos platform runs FLAPI as Cosmos Stratum Functions — Docker-packaged workers that satisfy all four requirements above. Each Stratum Function invocation processes "a single clip or sub-segment of a clip and shut[s] down again to free up resources" (Source: sources/2026-04-24-netflix-scaling-camera-file-processing-at-netflix).

Netflix's explicit runtime contract:

"Factors that are essential for tools in our runtime environment include that they: * Are packageable as Serverless Functions in Linux Docker images that can be quickly invoked to run a single unit of work and shut down on completion * Can run on CPU-only instances to allow us to take advantage of a wide array of available compute * Support headless invocation via Java, Python, or CLI * Operate statelessly, so when things do go wrong, we can simply terminate and re-launch the worker"

This pattern unlocks Netflix's elastic-scaling posture for production workloads — see patterns/elastic-scaling-for-production-spikes for the scheduling + capacity story this pattern enables.

Consequences

Positive

  • Horizontal scale comes free — add more workers, get linear throughput.
  • Failure tolerance — a single function crash kills one clip-unit, not the whole job; re-launch is a retry.
  • Mixed workload packing — media-processing workers share the CPU pool with other encoding workloads (smooths demand across the shared pool).
  • Deployment consistency — the same Docker image runs in AWS and on Netflix's production compute centres, giving "consistent assessment of footage wherever it may exist."

Negative

  • Startup cost per unit — container launch + tool init per clip. Amortise across a large enough unit of work (a full clip, not a single frame).
  • Output location must be reachable durably — output storage is the only cross-invocation shared state, so it must be reliable and supporting appropriate concurrency.
  • Not ideal for short latency-critical pipelines where per-invocation startup is a measurable fraction of the whole job.

Known uses

  • Netflix MPS × FLAPI × Cosmos (2026-04-24) — canonical wiki instance. Cosmos Stratum Functions wrap Docker-packaged FLAPI for per-clip inspection + render + trim jobs across Netflix's global production footprint. Same Docker image runs in AWS and in local compute centres. (Source: sources/2026-04-24-netflix-scaling-camera-file-processing-at-netflix.)
Last updated · 550 distilled / 1,221 read