Building a Scalable Omegle Alternative: WebRTC Architecture and Real-Time Matchmaking

When building real-time browser communication apps, low latency and friction-free access are paramount. After classic random video platforms went dark, most modern replacements took a step backwards: heavy dependencies on server-side relays, coin/token gates, and invasive tracking scripts.

To test high-speed real-time matchmaking while preserving extreme user privacy, I built Hashgang Chat.

Here is a breakdown of how the architecture works under the hood and the lessons learned while routing thousands of ephemeral connections.

High-Level Architecture
The platform relies on two main building blocks:

• WebSocket Signaling Server: Manages room queues, user pairings, and signaling negotiation.
• Direct WebRTC Peer-to-Peer: Delivers low-latency video and audio directly between connected browsers.

Key Architectural Challenges & Solutions

1. The Queue & Matchmaking System Unlike traditional chat rooms where users join persistent channels, anonymous 1-on-1 chats require an ephemeral, FIFO-style matchmaking pool.

• When a client connects, they emit a join_queue event.
• If a peer is already waiting in the pool, the server creates a unique room ID, pairs both clients, and triggers the WebRTC handshake.
• If no peer is available, the client sits in the queue until the next socket connects.

Edge Case Handled: Fast disconnects. If a user hits "Next" or closes their tab before an SDP exchange finishes, the signaling server must prune stale socket IDs instantly to avoid pairing incoming users with a "ghost" peer.

1. Clean WebRTC Signaling The signaling server never touches raw video or audio packets. Its only job is to relay SDP (Session Description Protocol) messages and ICE candidates:

• Offer/Answer Handshake: Peer A generates an Offer, sends it via WebSocket to the server, which forwards it to Peer B. Peer B returns an Answer.
• ICE Candidate Exchange: As both browsers gather candidates (local network endpoints and public STUN/TURN routes), these are continuously forwarded until the optimal direct P2P link is established.
• Bandwidth Optimization: Keeping media streams purely peer-to-peer eliminates server bandwidth bottlenecks and preserves strict user privacy.

1. Ephemeral Sessions & Privacy by Design One of the core design philosophies of Hashgang Chat is the total elimination of session persistence:

• No databases storing chat logs or matching history.
• No account requirements (no JWT tokens, emails, or third-party auth providers).
• Whenever a user triggers a skip (next_peer), the active RTCPeerConnection instance is immediately closed and garbage collected on the client side before re-entering the signaling queue.

Check It Out
The platform is fully live and running in production. You can test the connection speed, video quality, and matching flow directly in your browser:

👉 Live Platform: https://chat.hashgang.com

If you have experience scaling real-time signaling architectures or handling dynamic STUN/TURN relay failovers under high concurrent loads, I’d love to hear your thoughts and insights in the comments!