How to horizontally scale rtcstats-server in a cluster

Scale rtcstats-server across multiple instances for high-volume WebRTC deployments.

For production deployments handling tens of thousands of concurrent sessions or more, a single rtcstats-server instance may not be sufficient. This guide covers how to horizontally scale rtcstats-server across multiple nodes.

When do you need to scale?

A single rtcstats-server instance can handle a significant volume of connections. Consider scaling when:

You have 1000's of concurrent connections for a single instance
CPU or memory utilization consistently exceeds 70-80%
WebSocket connection counts approach the instance's limit
You need high availability and zero-downtime deployments

Architecture overview

A horizontally scaled rtcstats-server deployment typically consists of:

                  ┌─────────────────────┐
                  │  Load Balancer      │
                  │  (sticky sessions)  │
                  └──────────┬──────────┘
                             │
              ┌──────────────┼───────────────┐
              │              │               │
    ┌─────────▼───┐  ┌───────▼─────┐  ┌──────▼──────┐
    │ rtcstats    │  │ rtcstats    │  │ rtcstats    │
    │ server #1   │  │ server #2   │  │ server #3   │
    └──────┬──────┘  └──────┬──────┘  └──────┬──────┘
           │                │                │
    ┌──────▼────────────────▼────────────────▼──────┐
    │              Shared Storage                   │
    │              (S3, or equivalent)              │
    └───────────────────┬───────────────────────────┘
                        │
              ┌─────────▼─────────┐
              │  Shared Database  │
              │       (SQL)       │
              └───────────────────┘

Key considerations

Machine size

In general, our preference is more, smaller machines to be used for rtcstats-server instances. Having a cluster of 2 machines is a good starting point for a moderately sized deployment while exercising the needed infrastructure for scaling the deployment.

For scaling the deployment it is best to look at CPU and memory percentage as well as free disk space using common cloud monitoring tools.

Sticky sessions (session affinity)

rtcstats-js maintains a WebSocket connection to a specific rtcstats-server for the duration of a session. The load balancer must route all WebSocket frames for a given session to the same server instance. This requirement is typically shared with the WebRTC signaling server.

If the rtcstats-server fails or the WebSocket connection gets severed, the rest of the session data from the rtcstats-js client will not be collected.

Shared storage

rtcstats-server uses the machine disk as scratch space for writing files in any ongoing session. Once the WebSocket connection is stored that session is considered complete and the resulting file will be uploaded to the shared storage space.

Shared database

Once the file is uploaded to the shared storage, the database will be updated with a pointer to the storage url from which other components like rtcstats-features or you can retrieve the file.

Stateless instances

rtcstats-server is a stateless instance. It holds no memory that needs to be migrated across instances. This is due to the fact that a connection that gets severed with any rtcstats-js client is considered lost. This greatly simplifies the architecture and the solution deployment.