# Real-time infrastructure for WebRTC and WebSockets at scale

Kitecorp builds and scales the infrastructure behind real-time products: WebSocket fleets that hold millions of open connections, WebRTC media servers and TURN relays that keep calls up when the network does not cooperate, and the load tests that prove it before a launch does.

Canonical: https://kitecorp.org/services/real-time-infrastructure

## What does a real-time engagement deliver?

A design for the connection layer: how clients connect, how connections are spread across nodes, what happens when a node restarts and how a message finds the sockets it is meant for. For WebRTC products, the media path: selective forwarding units, TURN relays, their placement near users and their scaling signals. The implementation on Kubernetes or plain instances, with the kernel, load balancer and network settings that real-time traffic needs and web defaults do not provide. Load tests that simulate the real client population. And observability built around the metrics that matter for real-time: connection counts, fan-out latency, packet loss and relay usage.

## How do WebRTC media servers and TURN scale?

Media servers scale on bandwidth and on the number of streams each forwards, not on CPU alone, so the autoscaling signal is usually outbound bandwidth per node. They need stable public addresses and open UDP port ranges, which means host networking or a node pool dedicated to media rather than the default pod network. TURN relays sit as close to users as possible, because every relayed call pays the relay's latency twice, and they are the component to watch on cost: relayed bandwidth is billed per gigabyte by every provider. The guide on [running a WebRTC SFU on Kubernetes](/guides/scaling-webrtc-sfu-on-kubernetes) covers the placement and the signals.

## How do we fan out messages to millions of WebSocket connections?

By never asking one process to know about every socket. Connections are spread across a fleet behind a load balancer that supports long-lived connections; each node knows only its own sockets; a publish/subscribe layer carries each message to the nodes that hold a subscriber for it; and the subscription index is sharded by room, user or topic so no single key becomes hot. Reconnection is designed in: clients resume with a cursor, and a node restart drains its connections rather than dropping them. The full walk-through is in the guide on [scaling WebSockets to millions of connections](/guides/scaling-websockets-to-millions-of-connections).

## How do we load test real-time systems?

With clients that behave like clients. Thousands of simulated connections, held open for the session lengths your product sees, sending and receiving at realistic rates, joining and leaving in the waves a launch or a live event produces. The test runs against the real stack, not a mock, and keeps going until something breaks: a node runs out of file descriptors, a relay saturates, a pub/sub shard goes hot. That breaking point, and the signal that preceded it, is what the capacity plan is built from.

## How does an engagement run?

A discovery call to understand the product, the client population and the launch date. A design for the connection and media layers, with the capacity targets stated as numbers. The implementation with your team, and the load tests that prove it. A handover with the dashboards, alerts and runbooks for a real-time on-call. Pricing follows the discovery call, once we know the scope.

## Frequently asked questions

### How many WebSocket connections can one server hold?

Hundreds of thousands on a well-tuned node, bounded by memory per connection and file descriptors long before CPU. The guide on scaling WebSockets walks through the limits and how to spread connections across a cluster.

### Do we need our own media servers for WebRTC?

For one-to-one calls, often not: peer-to-peer with a TURN relay as fallback is enough. For group calls, broadcasts or recording, a selective forwarding unit is the standard answer, and running it well on Kubernetes is most of the work.

### Can you load test real-time systems?

Yes. Thousands of simulated clients holding connections, sending at realistic rates and joining and leaving in waves, against the real stack, until something breaks. The breaking point becomes the capacity plan.

### Do you work with our existing team?

Yes. Every engagement is delivered with your engineers and ends with a handover, runbooks and alerts they own.

### How do we start?

Send a message through the contact page. We schedule a discovery call, agree the scope, and pricing follows what we find.

## How to start

Send a message at https://kitecorp.org/contact or email admin@kitelang.cloud. Pricing follows a discovery call.