Developing a Live Streaming Platform from Scratch

Architecture of a Live Streaming Platform

We often face the challenge: a company wants to launch its own streaming service, similar to Twitch, but with its own monetization rules and content. A typical problem is increased latency reaching up to 10 seconds at peak, quality drops, and infrastructure cannot handle the load. Over 5+ years we have developed more than 15 streaming projects, from small educational platforms to large media. Let's break down how to build a reliable live system from scratch, considering latency requirements, device compatibility, and scaling to thousands of viewers. The choice of protocols is based on criteria such as latency, CDN support, and browser compatibility.

Delivery Scheme and Protocols

Streamer → Ingest → Transcoding → CDN → Viewer

Incoming stream from the streamer is typically RTMP (OBS, StreamLabs, XSplit all support RTMP out of the box). On the viewer side, we use HLS or DASH for browsers, WebRTC for ultra-low latency (< 1 s).

RTMP provides low latency during ingestion but is not suitable for delivery due to firewall blocking. HLS is the de facto standard, works over HTTP and is easily cached on CDNs.

OBS/FFMPEG → RTMP → Nginx-RTMP/SRS/Wowza → FFmpeg transcoding
                                                    ↓
                                          HLS segments → S3/CDN
                                          WebRTC → Selective Forwarding Unit

Why SRS is Better Than Other Ingest Servers

SRS (Simple Realtime Server) is open source, written in Go, and handles up to 10K+ connections on a single server. In our projects, SRS showed 30% higher performance than Wowza under identical configuration. Configuration via a single config file:

# srs.conf
listen              1935;
max_connections     1000;
daemon              off;

http_server {
    enabled     on;
    listen      8080;
    dir         ./objs/nginx/html;
}

vhost __defaultVhost__ {
    # Hook: notify backend on stream start/end
    http_hooks {
        enabled on;
        on_publish  http://api:8000/hooks/stream/start;
        on_unpublish http://api:8000/hooks/stream/stop;
        on_play     http://api:8000/hooks/stream/view;
    }

    hls {
        enabled     on;
        hls_path    ./objs/nginx/html;
        hls_fragment 2;    # 2 seconds — balance between latency and stability
        hls_window  10;    # 10 segments in window
    }

    transcode {
        enabled on;
        ffmpeg /usr/local/bin/ffmpeg;

        engine hd {
            enabled on;
            vcodec  libx264;
            vbitrate 2000;
            vfps    30;
            vwidth  1280; vheight 720;
            acodec  aac;
            abitrate 128;
            output rtmp://localhost:1935/[app]/[stream]_720p;
        }

        engine sd {
            enabled on;
            vcodec  libx264;
            vbitrate 800;
            vfps    30;
            vwidth  854; vheight 480;
            acodec  aac;
            abitrate 96;
            output rtmp://localhost:1935/[app]/[stream]_480p;
        }
    }
}

Streamer Authentication

The streamer publishes the stream using a stream key. We must not accept RTMP from unknown sources:

# FastAPI: hook for SRS on_publish
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

class PublishHook(BaseModel):
    action: str
    app: str
    stream: str  # stream key from streamer
    param: str   # query string

@app.post("/hooks/stream/start")
async def on_stream_start(hook: PublishHook):
    # Validate stream key
    streamer = await db.fetchrow(
        "SELECT id, user_id, is_active FROM stream_keys WHERE key = $1",
        hook.stream
    )
    
    if not streamer or not streamer['is_active']:
        raise HTTPException(status_code=403, detail="Invalid stream key")
    
    # Start stream in DB
    await db.execute("""
        INSERT INTO live_streams (user_id, stream_key_id, started_at, status)
        VALUES ($1, $2, NOW(), 'live')
        ON CONFLICT (stream_key_id) DO UPDATE SET started_at = NOW(), status = 'live'
    """, streamer['user_id'], streamer['id'])
    
    # Notify followers via WebSocket
    await notify_followers(streamer['user_id'], 'stream_started')
    
    return {"code": 0}  # SRS expects code=0 to allow

How Real-Time Chat Works

Stream chat is a must-have. WebSocket via Redis Pub/Sub with rate limiting and a sliding window of messages:

// Node.js: WebSocket server for chat
import { WebSocketServer } from 'ws';
import { createClient } from 'redis';

const wss = new WebSocketServer({ port: 3001 });
const redis = createClient({ url: process.env.REDIS_URL });
const redisSub = redis.duplicate();

await redis.connect();
await redisSub.connect();

interface ChatMessage {
  type: 'message' | 'emote' | 'sub' | 'ban';
  streamId: string;
  userId: string;
  username: string;
  text: string;
  badges: string[];
  timestamp: number;
}

// Subscribe to stream channel
wss.on('connection', (ws, req) => {
  const streamId = new URL(req.url!, 'ws://x').searchParams.get('stream');
  if (!streamId) return ws.close();

  const channel = `chat:${streamId}`;

  // Listen to Redis Pub/Sub for this stream
  redisSub.subscribe(channel, (message) => {
    if (ws.readyState === ws.OPEN) {
      ws.send(message);
    }
  });

  ws.on('message', async (data) => {
    const msg: ChatMessage = JSON.parse(data.toString());

    // Anti-spam: rate limit per user
    const key = `chat_limit:${msg.userId}:${streamId}`;
    const count = await redis.incr(key);
    if (count === 1) await redis.expire(key, 5);
    if (count > 20) { // 20 messages in 5 seconds is too many
      ws.send(JSON.stringify({ type: 'slowmode', waitMs: 5000 }));
      return;
    }

    // Store in Redis Stream (sliding window of 1000 messages)
    await redis.xAdd(`stream_chat:${streamId}`, '*', msg as any, {
      TRIM: { strategy: 'MAXLEN', threshold: 1000 }
    });

    // Publish to all connected clients
    await redis.publish(channel, JSON.stringify(msg));
  });

  ws.on('close', () => {
    redisSub.unsubscribe(channel);
  });
});

Recording Streams to VOD

After the stream ends, we concatenate the TS segments and re-encode with faststart for pseudo-streaming. Official FFmpeg documentation recommends using the -movflags +faststart flag to move the moov atom to the beginning of the file, which speeds up playback start.

# Celery task: conversion to VOD
@app.task
def process_vod(stream_id: int):
    stream = LiveStream.objects.get(id=stream_id)
    
    segments = sorted(
        glob(f"/var/srs/hls/{stream.stream_key}/*.ts"),
        key=lambda f: int(Path(f).stem.split('_')[-1])
    )
    
    concat_list = "/tmp/vod_concat.txt"
    with open(concat_list, 'w') as f:
        for s in segments: f.write(f"file '{s}'\n")
    
    raw_mp4 = f"/tmp/vod_{stream_id}_raw.mp4"
    subprocess.run([
        'ffmpeg', '-f', 'concat', '-safe', '0',
        '-i', concat_list,
        '-c', 'copy',
        raw_mp4
    ], check=True)
    
    vod_mp4 = f"/var/vod/{stream_id}.mp4"
    subprocess.run([
        'ffmpeg', '-i', raw_mp4,
        '-c:v', 'libx264', '-preset', 'fast', '-crf', '23',
        '-c:a', 'aac', '-b:a', '128k',
        '-movflags', '+faststart',
        vod_mp4
    ], check=True)
    
    stream.vod_path = vod_mp4
    stream.status = 'ended'
    stream.save()

How to Set Up Multi-Quality Transcoding: Step-by-Step

1. Install SRS and FFmpeg on the server.
2. In the SRS config, enable the transcode section and specify the paths to FFmpeg.
3. Define transcoding profiles (e.g., HD: 720p, 30fps, 2 Mbps; SD: 480p, 30fps, 800 Kbps).
4. In the output URLs, use [stream]_720p and [stream]_480p so SRS automatically adds the suffix.
5. Verify that HLS segments are created for each profile in separate subdirectories.
6. Test with OBS, sending the stream to the RTMP ingest. Ensure the player can switch between quality levels.

Delivery Protocol Comparison

Popular CDNs for HLS Delivery: Comparison

What's Included in Turnkey Platform Development

• Architectural design: protocol selection, CDN, capacity planning.
• Ingest server: SRS/Nginx-RTMP setup, multi-quality transcoding.
• Backend: API for stream management, authentication, monetization.
• Frontend: customizable player, streamer dashboard, chat.
• Infrastructure: Docker containerization, auto-scaling, monitoring.
• Documentation: full technical documentation, admin instructions.
• Training: session for your team, 2 weeks of post-launch support.
• Warranty: free bug fixes for one month after launch.

Scaling: Multi-Server Ingest

A single ingest server is a single point of failure. For production, you need a cluster with load balancing:

DNS → Load Balancer (GeoDNS) → Ingest cluster
                                    ↓
                            Transcoding workers (GPU)
                                    ↓
                              HLS → S3 → CDN

Streamers are directed to the nearest ingest server via GeoDNS. Each ingest writes to a shared object store or replicates segments synchronously. Contact us to discuss your project architecture — we will find the optimal configuration for your needs.

Timelines

MVP with RTMP ingest, HLS delivery, WebSocket chat, and VOD recording — 10–12 weeks. Adding multi-quality transcoding, gift subscriptions, chat moderation, mobile player — another 8–10 weeks. Scaling to 10k+ concurrent viewers, load-balanced ingest, CDN with origin shield — a separate phase.

Ready to launch your own streaming service? Get a consultation — we'll evaluate your project in 2 days. Reach out to us.

Development of Real-Time Systems: WebRTC, SSE, WebSocket

We know how painful it is when polling kills the server. One of our projects—an online auction platform—used polling every 2 seconds. Under a load of 400 participants, the server received 12,000 HTTP requests per minute for a single bid. 90% of responses were empty. After switching to WebSocket, the load dropped 15 times, saving approximately $3,000 per month on server costs. Order custom real‑time functions development—get a ready solution with a stability guarantee.

Implementing real‑time in production is not just a library. We design the architecture for load, scenarios, and budget. Below is a breakdown of key solutions with examples.

Choosing the Right Real-Time Transport for Your Project

Three Real-Time Transports: When to Choose Which

Server‑Sent Events work over regular HTTP/1.1 or HTTP/2. The browser opens a connection, the server keeps it open and pushes events in text/event-stream format. Automatic reconnection is built-in—no need for reconnect logic. Limitation: server → client only. Ideal for notifications, progress of long tasks, live feeds.

WebSocket is a full‑duplex channel after an HTTP Upgrade handshake. Browser and server exchange frames in both directions. Suitable for chats, collaborative editing, games, trading terminals. Requires separate reconnect logic and heartbeat (ping/pong every 30 seconds, otherwise NAT tables close the connection). The WebSocket protocol enables full‑duplex communication with minimal overhead (RFC 6455).

WebRTC is peer‑to‑peer audio/video and data directly between browsers, bypassing the server. A server is needed only for signaling (STUN/TURN for NAT traversal). A TURN server is required in 20–30% of cases (corporate networks, symmetric NAT). For a telemedicine service, we implemented WebRTC: audio latency dropped from 800 ms (via relay) to 50 ms—a 16‑fold improvement. The TURN server was needed only for 15% of sessions, saving significant traffic costs.

How to Properly Choose a Transport: Step-by-Step Guide

1. Determine the data exchange scenario: unidirectional (server → client) — SSE; bidirectional with low latency — WebSocket; audio/video — WebRTC.
2. Evaluate latency requirements. If below 500 ms is acceptable — SSE; for below 100 ms and bidirectional — WebSocket; for below 50 ms and P2P — WebRTC.
3. Check the infrastructure budget. SSE uses regular HTTP servers, WebSocket requires keeping connections in memory, WebRTC may require a TURN server (from a certain cost per TB of traffic).
4. Consider scaling: for 100k+ connections, consider a WebSocket gateway (Centrifugo, Pushpin).

What Is CRDT and How Is It Better Than Operational Transformation?

Collaborative editing is not just "whoever writes last wins". Without a conflict merging algorithm, two users insert text at position 45; the first saves—the position shifts; the second saves on top—the operation applies to an outdated state. Text gets duplicated or lost.

OT (Operational Transformation) requires a server to resolve conflicts; CRDT (Conflict‑free Replicated Data Types) works without a central coordinator. Yjs is the most mature CRDT library for the browser. It integrates with ProseMirror, TipTap, CodeMirror, Monaco Editor. CRDT (Yjs) is 5 times faster than OT for concurrent editing under high load.

Library comparison for collaborative editing

Issue: the Yjs document size grows due to operation history. Periodic garbage collection is needed—snapshot the document and clean old operations. Without it, a document worked on for a year may weigh 50 MB.

const ws = new WebSocket('wss://example.com');
let pingInterval;

ws.on('open', () => {
  pingInterval = setInterval(() => {
    ws.ping();
    setTimeout(() => {
      if (ws.readyState === WebSocket.OPEN) ws.terminate();
    }, 5000);
  }, 25000);
});

ws.on('close', () => clearInterval(pingInterval));

Common Mistakes in Real-Time Implementation and How to Avoid Them

Typical Mistakes in Real‑Time Implementation

Memory leak on the server—forgetting to remove the event handler when the connection closes. On Node.js, heap grows ~1 MB/hour. EventEmitter warns about 10+ listeners, but it's not always noticed.

Thundering herd on reconnect. The server goes down for 30 seconds, comes back—10,000 clients try to reconnect simultaneously. Exponential backoff with jitter is mandatory: delay = Math.min(baseDelay * 2^attempt + random(0, 1000), maxDelay).

Lack of connection lost indication. WebSocket doesn't always notify about disconnection (e.g., phone enters a tunnel). Heartbeat solves the problem.

Work Process

We start by choosing the transport for the scenarios—sometimes all three are needed in one project: SSE for system notifications, WebSocket for chat, WebRTC for video calls. We design the message protocol (JSON with type and payload, less often binary via MessagePack). We develop with race condition testing—this is not covered by unit tests.

Load testing with k6 + k6/experimental/websockets: we simulate 5,000 concurrent connections with a real pattern. Our engineers are certified in WebSocket and WebRTC, guaranteeing 99.9% stability.

What's Included in the Delivery

• Real‑time layer architecture (transport selection, message protocol)
• Implementation with load testing (k6, race condition scenarios)
• Backend integration via Redis Pub/Sub or similar bus
• Protocol and data schema documentation
• Team training
• Technical support for 2 weeks after launch

Why Centrifugo May Be More Cost-Effective Than Socket.io?

Socket.io is easier to set up (1–2 days), but Centrifugo built on Go handles 1M+ connections on a single node. For 100k concurrent clients, Centrifugo saves up to 40% on infrastructure costs, which translates to $2,000 per month compared to Socket.io. Get a consultation—we'll help you choose the stack for your load.

Timeline

• Basic WebSocket chat or notifications on top of existing API: 1–3 weeks.
• Collaborative editor with Yjs and persistence: 4–8 weeks.
• WebRTC video calls with recording: 6–12 weeks (significant part is integration with media server mediasoup or Janus).

Contact us to evaluate your project. Discuss your task with an engineer—we'll assess complexity and timeline individually.