CASE STUDY · /bitolink

BitoLink — Real-Time Communication

Slack-style team messaging plus WebRTC audio/video — migrated from raw P2P to a LiveKit SFU for multi-party scale.

ROLE

Solo Lead Engineer · Real-Time Architecture

TIMELINE

2024

TEAM

1 (solo)

STATUS

Production

Overview

An internal Slack-equivalent communication platform: channels, threads, DMs, presence, and real-time audio/video calling — all in-browser.

Originally built on raw WebRTC P2P with Google STUN for NAT traversal. Hit scalability ceilings on 3+ participant rooms (client-side bandwidth, CPU). Migrated to LiveKit SFU to centralize media routing and unlock group calls.

The problem

Raw WebRTC P2P breaks down past 2 participants — every client uploads its stream to every peer. Group calls need a server that re-broadcasts streams, but it can't add unbounded latency.

What I built

Socket.io signaling for messaging, channels, threads, presence, read receipts, typing indicators
Initial WebRTC layer with Google STUN — direct P2P for 1:1 calls
Migrated to LiveKit SFU for multi-party — server routes media tracks, client only uploads once
Server-side room management API: dynamic join/leave, publish/subscribe control
Fault-tolerant Socket.io room lifecycle to handle disconnects/reconnects cleanly

Tech stack

WebRTCLiveKit SFUSocket.ioNode.jsReactTypeScriptGoogle STUN

Outcome

Sub-150ms latency on media, sub-100ms on messaging signals. Multi-party calls stable across flaky mobile networks via SFU fallback. Real production usage as the company's internal comms tool.

Want this in your stack? Let's talk.

Email Athar Back to all projects