Architecture

System Overview

┌─────────┐     ┌─────────────┐     ┌─────────────────────┐     ┌───────┐
│ Clients │────▶│  Socket.IO  │────▶│ webrtc-server-library│────▶│ Redis │
│(browser)│     └─────────────┘     └─────────────────────┘     └───────┘
    │                                          │
    │                                          ├── SocketManager
    │                                          ├── RTCSession (server-side)
    │                                          └── SFUManager (Cloudflare)
    │
    └──── webrtc-library (RTCSession, peers, media)
          Media: P2P or Cloudflare SFU (optional)

Components

Browser (webrtc-library)

The client runs in the user’s browser. It connects to the signaling server over Socket.IO, exchanges SDP offers/answers and ICE candidates, and manages RTCPeerConnection instances. Media is handled locally or via the SFU; it never passes through the server.

Socket.IO Signaling

All signaling (join, leave, mute, screen share, etc.) goes over WebSocket via Socket.IO. The server routes events between participants and updates session state.

webrtc-server-library

Manages Socket.IO connections, RTC session lifecycle (create, join, leave, end), and room state. It does not process or store media.

Redis

Redis stores session state (participants, user–session mappings) and powers the Socket.IO Redis adapter for multi-instance scaling. No media is stored in Redis.

Cloudflare SFU (Optional)

For larger meetings, media can be routed through Cloudflare Workers SFU. The server orchestrates SFU sessions; media flows through Cloudflare, not the VidioMeet server.

Media Path

Media never passes through the server. Audio and video flow directly between peers (P2P) or via the optional SFU. The server handles only signaling and session state.

State Storage

Session metadata, participants, and user–session mappings live in Redis. The server process is stateless; any instance can handle any connection when scaling horizontally.