Same WebSocket: chat was instant, video was seconds behind

transcript

Chat: instant. Video: seconds behind. Over the very same WebSocket. And a 5 million dollar investor demo is tomorrow.

3 AM at ConnectNow. Video drops to 240p. Delays of 2 to 5 seconds. You can't hold a conversation. Server CPU at 95 percent. With just 50 video calls.

User A's camera makes 30 frames a second. Each one goes to the server. The server processes every frame, then forwards it to User B. Every call, every user, through one place. Each new user multiplies the load.

For chat, that's perfect. Small messages, in order, and the server sees them all. For video, it's a bottleneck. The protocol wasn't broken. It was the wrong job.

So keep the WebSocket for chat, login, and one more job: introducing the browsers. Then the video goes direct, browser to browser, over WebRTC. Most devices sit behind NAT. A STUN server tells each browser its public address. The server never touches a video frame again.

But here's the catch. In testing, every call connects. In production, some users never get video. Often on corporate networks. That's often cited as 10 to 20 percent of connections. A TURN server relays them.

The result? CPU went from 95 percent with 50 users, to 15 percent with 500. Video from 240p to adaptive 1080p. Bandwidth from 50 cents a user-hour to 5. And the funding round? Series A, funded.

WebSockets for messages. WebRTC for media. Pick by the job, not by habit.

Full breakdown in the lecture.