How to Build a Live Streaming App: Architecture and Cost

Every conversation about live streaming app development eventually lands on one number: glass-to-glass latency, the time between light hitting the streamer's camera and the same frame appearing on a viewer's screen. Pick a target for that number and most of the architecture picks itself: the protocol, the infrastructure, and the per-viewer economics all follow. Video streaming app development has a reputation for being mysterious; in practice it is a chain of well-understood stages with a price tag attached to each one. This guide walks that chain: the latency tiers, the ingest-transcode-deliver pipeline, the interactive layer that sits on top, moderation for content that doesn't exist until it airs, and the math that decides what the whole thing costs to run.

The short version

• Glass-to-glass latency is the first architectural decision: pick a target and the protocol, infrastructure, and per-viewer economics all follow from it.
• Three latency tiers behave like three different products: sub-second WebRTC at 200 to 500 ms for two-way conversation, LL-HLS at 2 to 5 seconds for creator broadcasts with live chat, and standard HLS at 10 to 30 seconds for large one-to-many events.
• Every stream runs the same ingest, transcode, and deliver pipeline; transcode is metered on input minutes while delivery is metered on audience, so delivery (CDN egress) dominates the bill at any real scale.
• Rent the video pipeline first (Mux or Amazon IVS for HLS, LiveKit or Agora for WebRTC); building your own ingest, transcode, and CDN stack only pays off past tens of thousands of streamed hours per month.
• Delivery cost is concrete: a 720p stream is roughly 1.1 GB per viewer-hour, so one thousand viewers for one hour is about 1.1 TB and costs $22 to $88 in egress.
• Live moderation must be a sampling-and-response system with a measured kill-switch SLA, because live content does not exist until it is already in front of the audience.

Latency decides the architecture

There are three latency tiers in live video, and they are effectively three different products.

Sub-second: WebRTC, 200 to 500 ms. This is the conversational tier: live auctions where a bid has to land before the hammer, dating apps where two people actually talk, co-streaming, live shopping with real-time Q&A. WebRTC pushes media over UDP through an SFU (selective forwarding unit) that holds a stateful connection to every single viewer. There is no CDN cache to hide behind: cost scales linearly with concurrency, and a single SFU node tops out at hundreds to low thousands of subscribers before you shard and cascade. You pay for the immediacy.

2 to 5 seconds: LL-HLS. The creator-broadcast tier. One person streams, thousands watch, and the interaction happens in chat, which has its own, much cheaper, realtime channel. Low-Latency HLS slices the stream into partial segments a few hundred milliseconds long and serves them over plain HTTPS, which means an ordinary CDN can fan one stream out to 100,000 viewers from cache. A viewer three seconds behind the camera doesn't notice, because the chat feels live and that is what they're measuring.

10 to 30 seconds: standard HLS or DASH. The event tier: sports, conferences, product launches. Six-second segments, a three-segment buffer before playback starts, deep CDN caching at every layer. It is the cheapest per viewer-hour and the most resilient to bad networks, and for a one-to-million broadcast nobody is racing the feed.

The rule that falls out: latency and audience size pull against each other, and cost rises as latency drops. Hybrids are common and legitimate: co-streaming apps run WebRTC between the three people on stage, composite the result, and re-broadcast it to the audience over LL-HLS. What you should not do is pick features first and discover the latency requirement later; that mistake reads as a full rebuild.

The pipeline: ingest, transcode, deliver

Whatever the tier, live video moves through the same three stages.

Ingest. RTMP remains the default contribution protocol (every hardware encoder and OBS install on earth speaks it), and a streaming platform that can't terminate RTMP cuts itself off from the existing creator toolchain. WHIP, the WebRTC ingest standard, covers publishing straight from a browser or a mobile app without shipping a custom encoder. SRT earns its place where the uplink is hostile: bonded cellular, venues, anything moving. The ingest edge terminates the protocol, validates the stream key, and hands a single contribution feed (typically 1080p at 4 to 6 Mbps) to the transcoder.

Transcode. One input becomes an ABR (adaptive bitrate) ladder: 1080p at 4.5 Mbps, 720p at 2.5 Mbps, 480p at 1.2 Mbps, 360p at 800 kbps, 240p at 400 kbps is a representative five-rung ladder. The player measures available bandwidth and switches rungs mid-stream, which is why mobile viewers on a train see soft video instead of a spinner. This stage is the compute bill. VOD transcoding runs whenever capacity is cheap; live transcoding has to keep up with the wall clock for every concurrent input, on GPUs or very fast CPUs, or frames drop. Every rung you add to the ladder multiplies that work.

Package and deliver. The renditions get sliced into segments, manifests update continuously, and a CDN moves the bytes. Delivery is metered in egress (every viewer-minute is megabytes leaving the network), and at any real audience size it becomes the dominant line on the bill.

Then the build-vs-rent question, which in streaming has an unusually honest answer: rent first. Mux and Amazon IVS sell the whole HLS pipeline metered per input minute and per delivered minute; LiveKit and Agora sell the WebRTC tier per participant-minute. An API call replaces ingest edges, a GPU fleet, packaging, and a CDN contract. The crossover to owning the pipeline arrives when the monthly provider bill sustains at the cost of a small video-infrastructure team (in practice, tens of thousands of streamed hours per month with predictable utilization), and not before. Owning means warm GPU capacity sitting idle against spikes and an engineer on call who understands codecs. When we scope these builds, the rented pipeline survives into year two far more often than founders expect, and that is a compliment to the founders.

The interactive layer

The video pipeline is the part you can rent. The layer that makes a streaming app a product (chat, gifting, presence) is the part you build, and it has its own scaling physics.

Chat fan-out. A room with 10,000 viewers producing 50 messages per second means 500,000 message deliveries per second, from one room. The standard shape is WebSocket gateways in front of a pub/sub backbone (Redis Streams, NATS), with rooms sharded as they grow. Past a certain rate you stop delivering every message to every client and start sampling, because no human reads 50 messages per second anyway. Slow mode and per-user rate limits double as abuse controls and capacity controls.

Gifting. A gifting system is a double-entry ledger that happens to play an animation. Coins are purchased (through App Store and Google Play in-app purchase on mobile, with the store's commission priced into the coin bundle), coins convert to gifts, and gift value accrues to the creator's balance. Every write carries an idempotency key so a retried request can never double-spend, and every movement is auditable for refund and fraud review. That is the spend side. The payout side (KYC, balance splits, the rails that move money out) is its own discipline, covered in creator monetization platforms.

Presence. Viewer counts are approximate by design. Clients heartbeat, the server aggregates, the counter updates every few seconds and displays rounded. An exact realtime count costs real engineering and answers a question nobody asked.

Synced reactions. Hearts and emoji bursts must anchor to the media timestamp, not the wall clock. Viewers sit at different latencies; sync to wall clock and part of the audience sees the laughter arrive before the joke.

Moderating live content

Pre-publish review is impossible by definition: the content does not exist until it is already in front of the audience. Live moderation is therefore a sampling-and-response system, and it has to be designed like one.

Frames are sampled every 5 to 10 seconds per stream and pushed through vision models; audio is scored in rolling windows. Sampling cost scales with concurrent streams, so the rate is a budget dial, and it should be risk-tiered, with new accounts and previously flagged categories sampled harder than established streamers. Model confidence above a threshold routes the stream into a human review queue, where a reviewer sees the live feed plus a buffer of the preceding minutes.

The metric that matters is the kill-switch SLA: the time from a confident model flag or user report to the stream going dark, defined in seconds and measured the way you measure uptime. The mechanism matters too: termination has to revoke the stream at ingest, not merely hide the player in the app, or the feed lives on in restreams.

The legal frame is one line here, because it is not one line in real life: Apple and Google will not pass a UGC app through review without working reporting, blocking, and content controls, and the EU's Digital Services Act adds notice-and-action obligations on top. The full compliance picture for social products (DSA, COPPA, GDPR, and the app-store checklist) lives on our social media app development practice page.

Cost drivers and the infrastructure math

Streaming run-cost has two meters: input minutes and delivered gigabytes.

Transcode is metered on input. One streamer broadcasting for an hour is 60 input minutes through the ABR ladder (a few cents per minute on a rented pipeline), whether 10 people watch or 10,000. It is the predictable meter.

Delivery is metered on audience. A 720p rendition at 2.5 Mbps works out to roughly 1.1 GB per viewer-hour. One thousand viewers watching one hour is about 1.1 TB of egress; at $0.02 to $0.08 per GB depending on CDN commitments, that single streamed hour costs $22 to $88 to deliver. Audience is the multiplier, which is why delivery dwarfs transcode at any scale worth having, and why a viral night shows up on the invoice before it shows up in the press.

Concurrency spikes are the third driver. Live traffic is spiky by nature: one creator breaks out and concurrent transcode demand triples in an evening. GPU capacity cannot autoscale fast enough from cold, so someone holds warm headroom: either you, paying for idle capacity, or the provider, whose per-minute price includes exactly that service. This is most of what rent-vs-own actually decides.

The budget consequence for an MVP is clean: with the pipeline rented, engineering spend concentrates on the product layer (the apps, chat, gifting ledger, and moderation tooling), which is demanding but ordinary web development and mobile work, not video R&D. For how a streaming surface moves the total budget relative to a feed-based social product, see what a social media app costs.