Skip to main content

Platform Architecture

This page explains how the Native Frame platform works under the hood: the services that move a live stream from capture to playback, and the design choices behind them. It is a conceptual overview — for hands-on setup, follow the platform guides.

How the platform is built​

Native Frame's architecture is designed around three goals: scalability, reliability, and low latency. Every live stream flows through the same high-level pipeline:

Ingest → Process → Distribute

  • Ingest — a stream enters the platform from an encoder, camera, or browser.
  • Process — the platform routes, transcodes, and adapts the stream in real time.
  • Distribute — viewers receive the stream over the protocol best suited to their device and network.

Read the protocol labels rather than the boxes: WebRTC appears on both sides of the diagram and RTMP only on the left. WebRTC is both a way into the platform and a way out of it, while RTMP is ingest only — which is the distinction the note at the end of WebRTC vs. RTMP makes in prose.

Three services are deliberately absent from the drawing because they touch every box and would turn it into a web of lines: authentication servers gate both publishing and viewing, load balancers sit in front of each service tier, and analytics collect from all of them. Each has its own section below.

Each stage is handled by dedicated, independently scalable backend services. If you are new to the underlying vocabulary (bitrate, keyframes, latency), start with how live video streaming works.

Backend services​

The platform is composed of specialized services, each responsible for one part of the pipeline.

SFUs (Selective Forwarding Units)​

SFUs handle WebRTC connection routing. Rather than every participant sending a copy of their media to every other participant, each publisher sends a single stream to the SFU, which then selectively forwards it to the subscribers who need it. This keeps interactive, low-latency sessions efficient as participant counts grow.

Transcoders​

Transcoders process and modify streams in real time — changing resolution, bitrate, or codec. They are what make adaptive bitrate delivery possible (see Transcoding and adaptive bitrate below).

Origins​

Origins accept incoming RTMP streams. They are the entry point for traditional broadcast-style ingest, receiving the source stream before it is processed and distributed.

Load balancers​

Load balancers distribute incoming connections and traffic across available service instances, keeping any single node from becoming a bottleneck and supporting graceful scaling under load.

Authentication servers​

Authentication servers validate access to streams and platform resources, ensuring only authorized publishers and viewers can connect. For how to configure access, see Authentication.

CDN and edge servers​

The CDN and edge servers handle HLS distribution at scale and provide edge compute closer to viewers. Serving content from the edge reduces latency and offloads traffic from origin infrastructure.

Hybrid distribution​

The platform supports both HLS and WebRTC delivery, and runs a hybrid multi-region model that spans cloud and on-premise infrastructure. This lets deployments place capacity close to audiences and meet data-residency or infrastructure requirements without giving up global reach.

Choosing a protocol comes down to the trade-off between latency and reach:

  • WebRTC — ultra-low latency, ideal for interactive and real-time experiences.
  • HLS — highly scalable and broadly compatible, ideal for large broadcast-style audiences.
tip

The right protocol depends on your use case. For a full comparison of latency, scale, and compatibility, see Streaming protocols.

Transcoding and adaptive bitrate​

From a single input stream, transcoders produce multiple quality levels — or renditions — at different resolutions and bitrates. Adaptive bitrate (ABR) delivery then lets each viewer's player automatically select the rendition that best fits their device and current network conditions.

The result is the best possible quality for each viewer: high-resolution playback on a strong connection, and uninterrupted (if lower-resolution) playback when bandwidth drops. The set of available renditions and how a player switches between them is described in the manifest.

WebRTC vs. RTMP at the infrastructure level​

WebRTC and RTMP serve different roles in the pipeline:

  • WebRTC powers ultra-low-latency, interactive sessions where participants both publish and subscribe in near real time. It is routed through the SFUs.
  • RTMP provides robust, traditional broadcast ingest — a reliable way to push a source stream into the platform via the origins.
note

WebRTC and RTMP are ingest and interaction technologies. They are distinct from the delivery protocols (HLS and WebRTC) that carry the processed stream to viewers.

Analytics and monitoring​

Every component in the pipeline emits detailed statistics — including bitrate, packet loss, and jitter — giving visibility into stream health from ingest through delivery.

Analytics are available both in real time and historically:

  • Stream-level granularity is retained for approximately two weeks, for detailed per-stream investigation.
  • Aggregated metrics are retained longer, for trend analysis and capacity planning.

For how to access dashboards and query these metrics, see the Analytics guide.