Scalable Video Streaming and Conferencing in 2026: Architecture, Costs & Stabilisation Playbook

Why Fora Soft wrote this playbook

Fora Soft has spent 21 years shipping real-time video and streaming products. Our portfolio includes live-video education at scale on BrainCert, broadcast-grade billiards streaming on Kozoom, telemedicine, WebRTC-based courtrooms, OTT platforms and video surveillance systems. We have built, audited and rescued more of these systems than we can comfortably count.

This playbook is what we tell clients in Week 1 of a scaling engagement: how streaming and conferencing actually differ, where platforms break first, how to size them honestly, and what a realistic fix looks like. It draws on specific choices we use on production: Hetzner AX-series bare metal for transcoding, Cloudflare for edge delivery, mediasoup and LiveKit for SFU clusters, managed Kubernetes where it pays, plus a comparison of custom work vs Agora-style managed video.

If you are staring at a dashboard that is going red on product demos, our custom scalability modules are designed to plug in next to your existing stack and buy you the headroom you need before an architectural rebuild becomes unavoidable.

Streaming vs conferencing: two different scaling problems

Scaling decisions start with one question: what traffic pattern is the product? Broadcast (one publisher, many viewers) and conferencing (many publishers, many viewers) look similar on a pitch deck and behave nothing alike in production.

Why video platforms actually break — and why “more servers” does not help

When a video platform buckles during the webinar, the cricket final, the virtual classroom, the problem is rarely the total CPU count. It is almost always one of these five structural failures.

1. A single origin fanning out to every viewer. No CDN or an under-sized one. Egress saturates the first NIC that hits its cap; buffering spreads region-by-region.

2. A transcoder overloaded on a general-purpose VM. ABR ladders are CPU-expensive. Running 1080p60 H.264 on a shared t-class VM is the textbook source of stream drops.

3. SFU sized for “peak yesterday”. Conferencing SFUs saturate on egress bandwidth or port count. A single node comfortably holds 300–1000 concurrent audio+video tracks; past that you need cascade or autoscaling.

4. Stateful application servers. If the session state lives in the app process, you cannot horizontally scale it without sticky sessions or shared state. Move the state to Redis, Postgres, or a dedicated session store.

5. No observability. No rebuffer rate dashboard, no P95 startup time, no SFU CPU alert — you only find out when Twitter does. Monitoring is cheap. Rebuilding on fire is not.

Downtime is expensive. Recent Gartner/Information Technology Intelligence Consulting numbers put the average cost of enterprise downtime between USD 5,600 and USD 9,000 per minute. On a consumer live-stream event that is a fraction of the lost advertising, subscription cancellation and brand hit. A focused audit paid once is almost always cheaper than the next incident.

How scalable video systems are actually designed

The same six design principles show up on every well-scaled video product. They are not proprietary tricks; they are table stakes.

1. Stateless compute, stateful storage. API services carry no user state in memory. Sessions live in Redis; media state lives in the SFU or origin; business data in Postgres. Any service can die or scale without sticky routing.

2. CDN-first edge distribution. For broadcast: HLS/DASH packaged at the origin, cached on a CDN (Cloudflare, Fastly, Akamai, AWS CloudFront). 95–99% of viewer traffic never touches the origin. For low-latency: LL-HLS or WebRTC-over-CDN (Cloudflare, Phenix) to keep sub-second.

3. Adaptive bitrate (ABR). A ladder of renditions (e.g. 240p, 480p, 720p, 1080p at 400kbps/1.2Mbps/3Mbps/6Mbps) lets each viewer pick the highest quality their connection supports. Rebuffer rate drops by order of magnitude.

4. Horizontal SFU with cascade. Each SFU holds a cap (say 500 concurrent media streams). When a room grows past that, cascade the room onto a second SFU. mediasoup, LiveKit, Jitsi and Janus all support this; implementation details vary.

5. Transcoding on the right hardware. For serious broadcast we run transcoders on Hetzner AX-series bare metal with GPU (NVENC) or dedicated CPU. Elastic burst into AWS MediaConvert or Cloudflare Stream when spikes go past the fleet. Transcoding on a shared VM is a trap.

6. Monitoring and graceful degradation. Dashboard on P95 startup time, rebuffer ratio, error rate per region, SFU CPU, TURN bandwidth. Alarms at 70% of capacity. When things go wrong, drop non-essentials first: simulcast layers, 4K rendition, fancy filters. Keep the basic stream alive.

Reference architecture for a scalable video platform

The diagram below is the shape we default to for anything above a few thousand concurrent users. A small product uses a subset; an enterprise product adds regional replicas and private-origin redundancy.

Figure 1. Broadcast path (top) and conferencing path (bottom) share auth, billing and monitoring but split at the media plane.

Broadcast path (OTT, live events)

Ingest (RTMP, SRT, or WebRTC-WHIP) → transcoder fleet producing an ABR ladder → origin packaging to HLS/DASH + CMAF LL → CDN edge → player. Typical scaling unit: a region’s transcoder fleet sized for peak ingest, with an autoscaling group for spikes.

Conferencing path (meetings, rooms, interactive live)

WebRTC peer → SFU cluster → (optional) cascade SFU → WebRTC peer. TURN servers are sized independently based on symmetric-NAT prevalence in your audience (rule of thumb: 15–20% of users need TURN). For interactive live products (watch-along, e-learning), the conferencing stage may feed into the broadcast path via server-side RTMP egress.

Shared plane (auth, billing, analytics)

Identity, billing, user records and analytics are shared across paths. These services should be stateless, horizontally scaled, behind a regional load balancer, talking to a replicated Postgres or Aurora. Analytics events stream to Kafka or a managed equivalent, land in BigQuery/Redshift for reporting and a time-series store (Prometheus, Grafana Cloud) for operations.

Latency budgets that dictate your architecture

Before picking tools, pick the latency budget. Everything else follows.

When your platform is already on fire: the stabilisation playbook

Most platforms we audit are not broken beyond repair. They have two or three bottlenecks accounting for the vast majority of incidents. A focused 2–6 week intervention buys 10× headroom. The standard sequence:

Week 1 — audit and baseline. Measure P95 startup, rebuffer ratio, SFU CPU, origin egress, DB connection pool. Identify the top three bottlenecks. A written code and architecture audit becomes the map.

Week 1–2 — put a CDN in front of the origin. Same-day win for broadcast. Cloudflare or Fastly on the HLS/DASH endpoint reduces origin egress by 95–99% almost immediately.

Week 2–3 — containerise and auto-scale. Move stateless services into containers (Docker + Kubernetes or ECS). Autoscale on custom metrics (SFU CPU, transcoder queue depth) not just CPU.

Week 3–4 — move transcoding off the app path. Transcoders go to dedicated hardware or managed services (AWS MediaConvert, Cloudflare Stream, Wowza). Queue-based processing, not in-request.

Week 4–5 — cascade the SFU. For conferencing products. Cap each SFU at a known bandwidth or participant limit, cascade rooms across nodes, route by geography.

Week 5–6 — observability and runbooks. Grafana dashboards on the KPIs below. Alerts at 70% of capacity. Runbooks for the top five incidents. Blue-green or canary deployment so rollouts stop being outages.

Cost model: where the money actually goes

Two patterns to internalise:

Broadcast is egress-dominated. Once you have a CDN, compute is cheap and bandwidth is expensive. At scale you pay USD 0.005–0.04 per GB depending on contracted CDN and region. A 2 Mbps stream watched for 1 hour is ~900 MB, so roughly USD 0.01–0.04 per viewer-hour in egress. Transcoding is a fixed fleet cost amortised over all viewers.

Conferencing is compute-dominated. Managed services (Agora, Twilio, Daily, LiveKit Cloud) price per concurrent user or per minute — typical managed WebRTC lands USD 0.003–0.01 per participant-minute. Self-hosted SFUs on Hetzner or Equinix can be cheaper by 3–5× at steady-state scale but require a platform team.

Crossover: self-hosted SFU beats managed at roughly 30–50k participant-minutes per day, depending on geography. Below that, managed conferencing is almost always the cheaper total cost of ownership once you count engineering time.

Mini case: stabilising a live-video e-learning platform

Situation. A live-video e-learning product built on a monolithic Node server with a single SFU was collapsing at 300–400 concurrent users during the evening study rush in Asia. Webinars would degrade to audio-only, attendees would disconnect, CSAT in the app store collapsed.

What we changed in six weeks. We moved stateless services behind an ALB and autoscaled them on Kubernetes. We cascaded the SFU cluster (mediasoup) with four regional nodes — two EU, one US East, one Singapore. We put TURN behind a dedicated pool. We added Grafana dashboards for P95 startup, join failures and SFU CPU, with alerts at 70% capacity.

Outcome. Stable 8–10k CCU on the same product code, P95 join < 1.5s, rebuffer ratio down from 4.1% to 0.6%. Monthly infra cost went up by roughly USD 6k, avoided an estimated USD 400k rebuild, and unblocked a new enterprise tier. The pattern is repeatable across scalable video management systems and interactive live tools in general.

Want a similar assessment on your platform? Book a 30-minute call; we usually leave it with a one-page punch list you can ship next sprint.

A decision framework — scale your video platform in five questions

Q1. Broadcast or interactive? One publisher to many viewers → HLS + CDN. Many-to-many with <200ms interactivity → WebRTC SFU. Hybrid (live class with Q&A) → both, wired together.

Q2. What is the real latency budget? Write it down in milliseconds. Do not let anyone negotiate it up later without redesigning the pipeline.

Q3. What is the concurrency peak? Peak CCU is the number that sizes the fleet. Ordinary traffic hides the problem. Model the worst-minute of the worst-day you care about.

Q4. Managed or self-hosted media? Below ~30k participant-minutes/day managed wins on total cost. Above that, self-hosted pays back within a quarter if you have the team.

Q5. Who is on call? Video is 24/7. If there is no rotation with runbooks, you will pay that cost in outages instead of salaries.

Five pitfalls we see in almost every scaling project

1. Single origin for broadcast. No CDN, no cache layer. The first 500 viewers saturate the NIC; quality collapses region-by-region.

2. Stateful app servers. User or session state pinned to a process. No horizontal scale; sticky sessions become the new bottleneck.

3. One SFU for the world. Fine until the first global event. Cascade and regional SFUs are not optional past ~500 concurrent streams.

4. Transcoding on the app VM. CPU spikes crash the API. Move transcoding to its own fleet or a managed service.

5. Zero observability. No rebuffer dashboard, no startup-time histogram, no SFU CPU alert. You will find out when a customer tweets, not before.

KPIs: what to monitor every week

Quality KPIs. P95 startup time < 3 s (broadcast) or < 1.5 s (interactive). Rebuffer ratio < 1%. Video start failures < 0.5%. MOS ≥ 4.0 (conferencing). Glass-to-glass P95 inside the budget for your use case.

Business KPIs. Concurrent viewers, session duration, watch-through rate, churn by region, cost per viewer-hour or per participant-minute. These pay for the whole program.

Reliability KPIs. Origin and SFU CPU (alert at 70%), TURN bandwidth utilisation, error rate per region, P99 join latency, deployment failure rate, MTTR under 30 minutes. Treat the video plane like a payments system; if it is down, revenue bleeds.

When not to build custom scalability

Early MVP with unknown demand. Use managed services (Mux, Cloudflare Stream, LiveKit Cloud, Agora, Daily) to buy time. Custom pays off after you have a reliable growth curve.

Very small audience, very long product life. 200 active users on a tutoring app: managed forever. The engineering cost of DIY dwarfs the savings.

Team without WebRTC / streaming expertise. Self-hosted SFUs and transcoders are unforgiving. If you do not have — or cannot hire — that skill, stay managed.

Commodity use-case inside someone else’s ecosystem. A meeting widget inside an EMR usually belongs on Amazon Chime SDK or Zoom SDK, not on a bespoke SFU fleet.

FAQ

What to Read Next

Ready to scale your video platform without breaking it?

Scalability in video is never “buy more servers”. It is a set of structural decisions: stateless compute, CDN-first edge, ABR, horizontal SFUs, dedicated transcoders, serious monitoring. Streaming and conferencing each have their own version of this playbook; solving them with the same architecture is the most expensive mistake in the category.

Most platforms that are struggling today can be stabilised within six weeks. The remaining 20% need a more serious re-architecture, and that is usually worth doing once the stabilisation buys enough runway to plan it properly. Either way, measure the right KPIs, keep humans in the loop, and design for the growth curve you actually expect — not the one you hope for.