Streaming architecture guide
Choose where live video is controlled, processed, and multiplied
A streaming architecture is not one protocol or one diagram. It is a set of boundaries: where the source becomes compressed media, where contribution ends, where the live operation can be observed and recovered, where audience renditions are created, and how the result reaches viewers. Most production systems combine several patterns rather than choosing “CDN,” “edge,” or “peer-to-peer” as mutually exclusive answers.
The practical model
Begin with one source-to-viewer path and assign an owner and acceptance test to every handoff. A venue encoder may send SRT to a cloud or self-hosted control point. That layer can monitor, fail over, route, record, or transcode the feed. A publishing origin can then package outputs for a CDN, while viewers select renditions through a player. Edge compute, direct WebRTC sessions, or peer-assisted delivery can be added where their distinct behavior solves a measured problem.
The pulses identify handoffs, not measured latency. An architecture is accepted only when each boundary proves the intended media and recovery behavior.
Separate contribution, operations, and distribution
Contribution moves a production feed from a source to a controlled receiver. The source might be a truck, stadium, studio, church, conference room, mobile journalist, surveillance location, or software production. This leg usually has a small number of known endpoints and may need transport recovery, encryption, identity, or low operational delay.
Live operations decide which signal is active and what should happen to it. This is where teams monitor feeds, switch to a backup, create routes, record assets, add processing, and expose state to operators or an API. Combining this layer with the audience CDN can work in a small system, but treating them as separate responsibilities prevents viewer scale from obscuring contribution health.
Distribution turns an accepted program into something many devices and networks can play. An origin may create or expose manifests and segments; a CDN caches and delivers them from distributed infrastructure; the player requests an appropriate rendition. A successful contribution connection does not prove this audience path, and a healthy viewer manifest does not prove the original source can recover.
Six recurring architecture patterns
Direct encoder to platform
A camera, appliance, or software encoder sends directly to one streaming platform. It is easy to understand and can be sufficient for a small production. The encoder owns the destination credentials and reconnect behavior, and adding a second destination or central monitoring often means changing the source-side operation.
Use when: one source, one destination, and a simple recovery plan are genuinely enough.
Gateway and routing control
Sources send to a controlled ingest point, commonly over SRT or RTMP. Operators validate inputs there and create separate outputs for platforms, production tools, Multiview, recording, or downstream systems. The gateway becomes an observable boundary between contribution and delivery.
Use when: several sources or destinations, access control, monitoring, recording, or failover must not live inside each field encoder.
Origin plus CDN
An origin prepares live or on-demand media for scalable playback, and the CDN distributes requested objects through its edge network. This is the conventional pattern for large browser, mobile, and connected-TV audiences. Capacity, cache behavior, origin protection, playback format, geography, and cost all need explicit design.
Use when: many viewers need compatible playback and the origin should not serve every request directly.
Edge processing
Compute or media processing runs closer to a venue, device population, or audience region. It may reduce backhaul, localize decisions, or keep an operation available when a central dependency is impaired. “Edge” describes placement, not one product or protocol; orchestration and state reconciliation become part of the design.
Use when: local processing, constrained backhaul, geographic policy, or site autonomy has a measurable value.
Interactive WebRTC with an SFU
Interactive participants publish real-time media to a selective forwarding unit, which forwards chosen streams to other participants. This avoids asking every browser to upload one copy to every peer while preserving participant-level media. Recording, broadcast output, large passive audiences, and moderation may require additional layers.
Use when: two-way participation and low interaction delay matter more than conventional one-to-many delivery economics.
Peer-assisted delivery
Some viewers exchange media data with other viewers while an origin or CDN remains part of the system. This can reduce central delivery load in suitable environments, but browser support, peer availability, startup, privacy, network policy, and unpredictable upload capacity constrain it. Pure peer-to-peer is rarely a universal replacement for controlled origin delivery.
Use when: the audience and playback technology have been qualified and peer assistance has a measured operational or economic benefit.
CDN and edge computing are related, not interchangeable
A CDN is optimized to deliver content from distributed cache and serving infrastructure. Edge computing runs application or media logic at distributed locations. A CDN edge may offer compute, and an edge processor may cache media, but the design questions differ.
| Pattern | Primary job | State to operate | Failure to rehearse |
|---|---|---|---|
| Gateway/control layer | Accept and supervise contribution, then route or process selected feeds. | Sessions, identities, metrics, active/backup paths, outputs, recordings, and operator actions. | One source disappears while other routes must remain healthy. |
| Origin and CDN | Publish and scale playback to many viewers. | Manifests, segments, renditions, cache behavior, origin load, geography, access, and delivery errors. | Origin or regional delivery impairment during an audience spike. |
| Edge processing | Move compute, conversion, or decision-making near a site or region. | Deployment version, local resources, connectivity, configuration, and central/edge state. | Loss of the central link while local operation continues or degrades safely. |
| WebRTC SFU | Forward participant media for real-time interaction. | Rooms, participants, subscriptions, network estimates, media state, moderation, and TURN reachability. | A participant changes network or a relay path is required. |
| Peer-assisted delivery | Supplement centralized distribution with viewer upload capacity. | Peer availability, fallback delivery, privacy, browser support, and quality impact. | Peers vanish or enterprise networks block the peer path. |
Hybrid cloud and self-hosted designs
Cloud and self-hosted are placement choices, not opposing product categories. A contribution receiver can run near a cloud destination while a recorder stays on premises. A venue can keep local Multiview and failover while forwarding only the selected program upstream. A central team can operate several remote nodes through consistent workflows while each site retains an approved local recovery path.
The important work is mapping dependency and ownership:
- Which media must cross the public internet, a private link, or a site boundary?
- Which operation must continue if cloud connectivity fails?
- Where do recordings live, and who verifies they are complete and retrievable?
- Which credentials and ports are exposed at each boundary?
- Which state is centrally automated, and which local action remains safe during an incident?
- Can operators tell whether the active signal is local, primary cloud, or backup?
Design the architecture from constraints
- Count sources and destinations separately. Ten venue feeds feeding one program is a different system from one program feeding ten platforms.
- Classify participants and viewers. Interactive speakers, operators, passive viewers, and machine receivers have different latency, control, and scale needs.
- Set recovery objectives by boundary. Decide what may reconnect automatically, what must fail over, what can pause, and what requires an operator decision.
- Model the hardest media. Include peak motion, highest resolution, audio-channel count, captions or metadata, and concurrent recordings or transcodes.
- Map shared dependencies. Two encoders using one power feed, two ISPs entering one router, or primary and backup outputs on one host may not provide the independence their labels imply.
- Test audience scale outside the contribution test. A clean SRT input is not a CDN load test. A successful player request is not a venue-network rehearsal.
- Make cost follow traffic and compute. Estimate contribution egress, transcoding hours, storage and retention, origin delivery, CDN transfer, and interactive relay use from the architecture actually selected.
Where Callaba fits
Callaba is the operational control layer in the middle of these designs. It can receive live feeds, expose them to operators in Multiview, use live-video failover, create routes and restreams through Multistreaming, attach recording, and run transcoding. It can be launched in AWS or installed on controlled Linux infrastructure.
That does not turn every workflow into one opaque box. The field encoder still owns its source and encode. A destination platform still owns its ingest contract and audience service. A CDN still owns its distribution behavior. The value of the control layer is to make the live boundary visible and operable between them.
A small architecture review that prevents large mistakes
Draw one page with named sources, transport roles, ports or trust boundaries, processing modules, recordings, primary and backup paths, origin, CDN, and viewer surfaces. Beside every arrow, write what proves that handoff works. Beside every component, write its owner and safe restart. Then run four tests: remove one source, interrupt one network path, stop one processing output, and test playback from outside the production network.
If the diagram cannot say which feed is active, where the latest good recording exists, or what an operator may restart without affecting other destinations, the architecture is not ready to be automated. Add API control only after the manual state and recovery model are understood; otherwise automation reproduces ambiguity faster.
Prototype the middle of the workflow before scaling the edges
Bring one representative source into Callaba, prove monitoring and recovery, attach one recording and one destination, then test the actual audience path. That small slice reveals the boundaries your final architecture must preserve.
