10 min read

Beyond the Monolith: Rearchitecting for Laminar Flow at 100,000-Core Scale

Laminar Flow: Architecting for 100,000-Core Scale

Beyond the Monolith: Rearchitecting for Laminar Flow at 100,000-Core Scale

Imagine a world where 10 million people are shouting, cheering, and reacting in real-time, and your job is to make sure every single pixel of that chaos reaches them in less than two seconds. At Twitch, this isn’t a hypothetical; it’s a Tuesday night.

For years, our video ingestion and transcoding pipeline was the heart of the platform. It was a massive, high-performance beast that took raw RTMP streams from creators and turned them into the multi-bitrate HLS streams you watch on your phone, desktop, or console. But as the internet moved toward 4K, AV1, and hyper-interactive features, our legacy architecture—a monolithic, process-per-stream model—began to show its age. It was “turbulent.” A single failure in a transcoding unit could kill a stream; adding a new feature meant re-engineering a massive binary.

To survive the next decade of live video, we had to change the fundamental physics of how we process data. We moved from a rigid, monolithic pipeline to a fluid, dataflow-driven architecture we call Laminar.

This is the story of how we migrated one of the world’s largest live video platforms to a distributed stream processor, scaling to over 100,000 CPU cores while maintaining sub-second latency and five-nines of reliability.


The Architecture of Turbulence: The Monolith Problem

To understand why we built Laminar, you have to understand the “Legacy Transcoder.” Historically, Twitch operated on a Worker-centric model. When a streamer went live, a centralized orchestrator would find a beefy machine in one of our points of presence (PoPs), spin up a massive C++ process, and hand it the entire responsibility for that stream.

This process did everything:

  1. Ingestion: Terminating the RTMP/SRT connection.
  2. Demuxing: Breaking the container into raw video/audio packets.
  3. Decoding: Turning compressed bits into raw YUV frames.
  4. Scaling & Filtering: Resizing 1080p to 720p, 480p, etc., and applying overlays.
  5. Encoding: Compressing those frames into multiple qualities using x264 or hardware encoders.
  6. Packaging: Wrapping them into HLS segments and uploading them to the edge.

The Breaking Point:

  • Blast Radius: If the encoder thread crashed due to a weird input packet, the entire ingestion point died. The streamer disconnected. The audience saw a “2000: Machine Core” error.
  • Resource Inefficiency: A 1080p60 stream needs a lot of CPU. A 480p30 stream needs very little. But we were binning these into fixed-size instances, leading to “fragmented” CPU cycles that we couldn’t easily reclaim.
  • Development Velocity: Adding a new codec like AV1 or a feature like per-scene lookahead required modifying a 500,000-line C++ monolith. It was like performing heart surgery on an athlete while they were running a marathon.

We needed a system where video processing behaved like water in a pipe: smooth, predictable, and modular. We needed Laminar Flow.


The Laminar Philosophy: Video as a Dataflow

In a “Laminar” system, we don’t think about “servers” or “processes.” We think about Nodes and Edges in a Directed Acyclic Graph (DAG).

Instead of one giant process doing everything, we decomposed the transcoding pipeline into a series of micro-tasks. Each task is a discrete functional unit. One node decodes. One node scales. One node encodes. Data “flows” between these nodes via a high-performance backplane.

The Anatomy of a Laminar Node

Every node in the Laminar ecosystem follows a strict contract:

  • Input Buffers: Asynchronous queues that handle backpressure.
  • The Transform: A pure (or nearly pure) function that processes a frame or packet.
  • Output Buffers: Downstream distribution.

By decoupling these, we can run the Decoder on a CPU-optimized instance and the Encoder on a machine with dedicated ASIC hardware (like the AMD/Xilinx Alveo or NETINT cards).


Engineering the Control Plane: The Global Orchestrator

When you’re managing 100,000+ cores spread across the globe, you can’t rely on a single leader. Laminar uses a tiered control plane architecture.

  1. The Regional Brain: Each AWS region or bare-metal PoP runs a local controller. It monitors heat maps of CPU and hardware encoder utilization.
  2. The Stream Scheduler: When a stream starts, the Scheduler doesn’t look for a “Transcoder Server.” It looks for “Capability Units.” It asks: “Where can I place a 1080p Decode task, three Scale tasks, and five Encode tasks?”

The “Just-in-Time” DAG

Laminar doesn’t use a static configuration. It constructs the processing graph dynamically. If a streamer has “Low Latency” enabled, the Scheduler injects a Latency-Optimizer Node into the graph. If they are part of a beta for a new AI-denoiser, an Inference Node is shimmed between the Decoder and the Scaler.

# Example of a simplified Laminar Pipeline Definition
pipeline:
    id: "stream_ninja_123"
    nodes:
        - id: "ingest_0"
          type: "SRT_INGEST"
          config: { port: 9001 }
        - id: "decoder_0"
          type: "NVDEC_H264"
          inputs: ["ingest_0"]
        - id: "scaler_720p"
          type: "CUDA_RESIZE"
          config: { width: 1280, height: 720 }
          inputs: ["decoder_0"]
        - id: "encoder_720p"
          type: "X264_ENCODE"
          config: { bitrate: "3500k", preset: "veryfast" }
          inputs: ["scaler_720p"]

The Data Plane: Moving Pixels at Light Speed

The biggest challenge in a distributed video processor is the “Tax of Distribution.” If you move raw 1080p60 YUV frames over a standard network, you will saturate a 10Gbps link in seconds. A single uncompressed 1080p60 stream is roughly 3 Gbps.

To make a 100,000-core distributed system viable, we had to implement three critical optimizations:

1. Zero-Copy Shmem (Shared Memory)

When nodes are co-located on the same physical silicon, we don’t move data. We move pointers. We built a custom shared-memory transport that allows the Scaler node to write a frame into memory and the Encoder node to read it without a single memcpy(). This reduced our internal bus pressure by 70%.

2. Region-of-Interest (RoI) Tiling

For nodes that must be separated by a network hop, we don’t send the whole frame. We use RoI tiling. If only a portion of the screen changed (e.g., a webcam in the corner of a static game), we only transmit the dirty tiles.

3. Backpressure-Aware Scheduling

In traditional stream processing (like Flink), if a sink is slow, the source slows down. In live video, you can’t tell the streamer to “slow down.” If an encoder node falls behind, the Laminar Dataflow engine performs Intelligent Frame Dropping. It prioritizes keyframes (I-frames) and drops disposable B-frames to ensure the audio never de-syncs and the “live-head” stays current.


Scaling to 100,000 Cores: The Infrastructure Realities

Scaling to this level isn’t just about writing good code; it’s about managing the “Chaos of the Real World.” At any given moment, 0.5% of our fleet is failing. A dimm is throwing ECC errors; a NIC is flapping; a kernel is oom-ing.

The “Hot-Swap” Resume: In the old monolith, if a machine died, the stream died. In Laminar, the Global Orchestrator detects a node heartbeat failure within 200ms. Because the state of the stream (the Sequence Parameter Sets and Picture Parameter Sets) is mirrored in a distributed state store (built on top of a highly-available Etcd/Redis cluster), a new node can be spun up on a different core and “attach” to the existing flow. The viewer sees a minor stutter for 500ms instead of a total stream collapse.

The Spot Instance Strategy: Because Laminar is incredibly resilient to individual node failure, we can run a significant portion of our non-critical “transcode-only” workloads on AWS Spot Instances. This allows us to access massive compute capacity at a fraction of the cost, with the Dataflow engine automatically re-routing “flows” when AWS reclaims an instance.


The Hardware Revolution: ASICs and the Future of AV1

One of the primary drivers for the Laminar migration was the industry shift toward AV1. AV1 is roughly 30% more efficient than H.264, but it is notoriously expensive to encode on general-purpose CPUs.

To deliver AV1 to millions of viewers, Twitch collaborated on the development of custom hardware. But integrating custom PCIe hardware into a monolithic software stack is a nightmare.

Laminar made hardware integration “Plug-and-Play”: We created a Hardware Abstraction Layer (HAL) node. To the rest of the Laminar graph, it doesn’t matter if the “Encoder Node” is an x264 software process running on an EPYC processor or a hardware-accelerated AV1 core on a custom ASIC.

This modularity allowed us to:

  • Deploy new hardware into our data centers.
  • Update the “Encoder Node” binary to support the new driver.
  • Instantly route 5% of traffic to the new hardware to “Canary” it.
  • Scale up to 100% without touching the Ingest or Packaging logic.

Observability: Seeing Into the Pipe

You can’t manage 100,000 cores with top or htop. We built a custom observability suite that visualizes the “health of the flow.”

We track Micro-Jitter. Since live video is sensitive to timing, we measure the “inter-arrival time” of frames between nodes. If we see that the jitter is increasing between a Decoder and a Scaler, it’s a leading indicator that the CPU on that specific socket is being throttled or is experiencing cache contention. Our orchestrator can preemptively move the “flow” to a cooler part of the cluster before the user ever sees a dropped frame.

We also use eBPF (Extended Berkeley Packet Filter) extensively. By hooking into the Linux kernel, we can see exactly how long a video packet spends in the TCP stack versus the Laminar application layer. This was instrumental in debugging a “long-tail” latency issue where 0.1% of viewers in South America were experiencing 5-second delays due to bufferbloat in intermediate ISP routers.


The Impact: By the Numbers

The migration to Laminar wasn’t just an architectural exercise; it fundamentally changed Twitch’s economics and capabilities.

  • Compute Efficiency: We saw a 30% increase in CPU utilization across the fleet. By breaking the monolith, we eliminated the “stranded capacity” problem.
  • Latency: Average “Glass-to-Glass” latency (from the streamer’s camera to the viewer’s screen) was reduced by 15%, thanks to the elimination of internal process-handover bottlenecks.
  • Reliability: Stream-killing “Transcoder Crashes” dropped by 92%. Failures are now localized to individual nodes and recovered in milliseconds.
  • Developer Velocity: We recently integrated a new audio-processing library. In the old system, this would have taken 3 months. With Laminar, it was a new node type, tested in isolation and deployed via a config change in under two weeks.

The Road Ahead: AI and Beyond

As we look toward the future, the “Dataflow” model is opening doors we hadn’t even considered. We are currently experimenting with ML-based Bitrate Laddering.

Instead of encoding every stream into 720p, 480p, and 360p, a “Laminar Analysis Node” looks at the complexity of the video. Is it a high-motion shooter like Apex Legends or a static “Just Chatting” stream? The graph dynamically adjusts the encoding parameters—and even the number of nodes—in real-time to provide the highest possible quality for the lowest possible bandwidth.

We’re also exploring Edge-Compute Transcoding. With Laminar’s modularity, we can run the “Lightweight Ingest” nodes on edge servers closer to the streamer, while keeping the “Heavy Transcode” nodes in centralized, cost-effective data centers.

Smooth Flow, Massive Scale

Rearchitecting a system of this magnitude while it’s under constant load is often compared to rebuilding a plane in mid-air. But for us, it was more like turning a turbulent, crashing waterfall into a series of controlled, powerful, and laminar streams.

The shift to a dataflow-driven architecture has turned our video pipeline from a bottleneck into a competitive advantage. We’ve moved away from managing “servers” and toward managing “intent.” We don’t ask the system to “Run this binary”; we ask it to “Process this stream.”

And with 100,000 cores humming in the background, the “Laminar Flow” is just getting started. Whether it’s 10 million viewers or 100 million, the pipes are ready.


Are you interested in the intersection of distributed systems and high-performance video? Twitch is always looking for engineers who want to push the boundaries of what’s possible with Go, C++, and Rust in the world of live streaming. Check out our careers page to join the team building the future of the “Laminar” ecosystem.


More to explore

Keep diving in