Loading...
{
"auth": {
"login": {"method": "POST", "path": "/auth/login"},
"refresh": {"method": "POST", "path": "/auth/refresh"},
"logout": {"method": "POST", "path": "/auth/logout"}
},
"meetings": {
"create": {"method": "POST", "path": "/meetings"},
"get": {"method": "GET", "path": "/meetings/{meetingId}"},
"join": {"method": "POST", "path": "/meetings/{meetingId}/join"},
"leave": {"method": "POST", "path": "/meetings/{meetingId}/leave"},
"delete": {"method": "DELETE", "path": "/meetings/{meetingId}"}
},
"chat": {
"sendMessage": {"method": "POST", "path": "/chat/{meetingId}/messages"},
"getMessages": {"method": "GET", "path": "/chat/{meetingId}/messages"},
"sendReaction": {"method": "POST", "path": "/chat/{meetingId}/reactions"}
},
"recordings": {
"start": {"method": "POST", "path": "/recordings/{meetingId}/start"},
"stop": {"method": "POST", "path": "/recordings/{meetingId}/stop"},
"getMetadata": {"method": "GET", "path": "/recordings/{meetingId}"},
"download": {"method": "GET", "path": "/recordings/download/{recordingId}"}
},
"signaling": {
"websocket": {"path": "/ws/signaling", "events": ["join", "offer", "answer", "ice-candidate", "leave", "mute", "unmute"]}
},
"sfu": {
"assign": {"method": "POST", "path": "/sfu/assign"},
"status": {"method": "GET", "path": "/sfu/status/{sfuId}"},
"forward": {"method": "POST", "path": "/sfu/forward"}
}
}
Purpose
The Global Load Balancer is the first entry point for clients. It routes user traffic to the closest or healthiest regional deployment. It provides TLS termination, traffic routing, and DDoS protection.
Technologies
Notes
Often combined with CDN and edge security filtering.
Purpose
Handles HTTP/HTTPS traffic from clients and routes it to backend microservices. Provides request routing, rate limiting, and authentication verification.
Technologies
Notes
This layer usually handles:
Purpose
Handles user authentication and authorization. Issues tokens and validates sessions.
Technologies
Implementation languages:
Notes
Usually provides:
Purpose
Manages meeting lifecycle:
Technologies
Backend frameworks:
Notes
Stores meeting metadata and coordinates signaling.
Purpose
Handles real-time messaging inside meetings.
Features:
Technologies
Real-time messaging:
Backend frameworks:
Notes
Often uses event streaming to scale chat processing.
Purpose
Records meetings and stores video/audio streams.
Responsibilities:
Technologies
Media processing:
Storage:
Notes
Often records streams from SFU servers.
Purpose
Stores temporary real-time state such as:
Technologies
Notes
Chosen because of extremely low latency.
Purpose
Stores structured application data.
Examples:
Technologies
Notes
Supports ACID transactions and relational queries.
Purpose
Stores chat messages and conversation history at scale.
Technologies
Notes
Optimized for high-volume writes.
Purpose
Routes WebSocket connections to signaling servers.
Technologies
Notes
Supports persistent WebSocket connections.
Purpose
Handles WebRTC signaling between clients.
Responsibilities:
Technologies
Libraries:
Purpose
Manages allocation of meetings to SFU servers.
Responsibilities:
Technologies
Notes
Often implemented as a lightweight control service.
Purpose
Selective Forwarding Units handle media routing.
They:
Technologies
Notes
This is the core component of large video systems.
Purpose
Enable NAT traversal for WebRTC connections.
STUN:
TURN:
Technologies
Notes
TURN servers must be geographically distributed.
Purpose
Collects performance and system metrics.
Technologies
Notes
Used for monitoring latency, packet loss, and CPU usage.
Purpose
Centralized logging system for debugging and auditing.
Technologies
Notes
Helps diagnose signaling and media issues.
The signaling servers coordinate WebRTC session setup between clients. They do not carry media; they only exchange control messages needed to establish peer connections with the SFU.
Responsibilities include:
Media flows directly between the client and the SFU after signaling completes.
Signaling servers are designed to be stateless. Persistent or shared state is stored in Redis.
Scaling architecture:
Clients -> Signaling Load Balancer -> Signaling Server Pool
If a signaling server fails:
High-performance signaling servers typically use an event-loop model (Node.js, Go, or Rust).
Each server can handle roughly:
50,000 – 100,000 concurrent WebSocket connections
Optimization techniques include:
WebSocket connections must remain on the same signaling server.
Common strategies:
hash(client_id) -> server
or
cookie-based load balancer affinity
Stateless signaling servers
Pros:
Cons:
Sticky sessions
Pros:
Cons:
SFU stands for Selective Forwarding Unit.
An SFU receives media streams from participants and forwards them to other participants without decoding or mixing the media.
For a meeting with N participants:
N uplink streams (each participant sends one stream)
N*(N-1) downlink streams (each participant receives streams from others)
Example:
6 participants:
6 uplinks
30 downlinks
In a peer-to-peer mesh network:
connections = N(N-1)/2
Example:
10 participants:
45 peer connections
This quickly becomes impossible for browsers to handle.
SFU architecture simplifies this:
Client -> SFU -> Clients
Each client only maintains a small number of connections.
The orchestrator assigns rooms to SFUs and manages cluster load.
Responsibilities include:
A simple scoring approach:
score = w1 * cpu_usage
+ w2 * bandwidth_usage
+ w3 * number_of_rooms
The orchestrator chooses the SFU with the lowest score.
SFU architecture
Pros:
Cons:
MCU architecture
Pros:
Cons:
Redis stores ephemeral distributed state required by multiple services.
Used for:
User joins a meeting: