Simulator controls
~55 msDelivery latency
1 connServer load / user
The message's journey, step by step
Client emits. Your browser sends
{room:"dev", text:"hi"} over an already-open WebSocket — no new TCP/TLS handshake, so it costs a few milliseconds.Server validates & persists. The server (Node + Socket.IO, or Go, or Elixir/Phoenix) checks auth, writes the message to a database (Postgres/Mongo/Redis stream) so history survives restarts.
Fan-out. The server looks up every socket subscribed to the room and pushes the payload to each — that's the burst you see in the 3D scene. With multiple server nodes, a Redis pub/sub layer relays between them.
Clients render. Each client appends the message and sends read receipts / typing events back on the same connection.
WebSockets vs. polling — the actual numbers
Polling every 3 seconds means each user makes ~1,200 requests per hour even when nothing happens, and messages wait on average half the poll interval (1.5 s) before delivery. A WebSocket is one persistent connection with ~50 ms delivery and near-zero idle cost.
| WebSocket | Polling (3 s) | |
|---|---|---|
| Avg delivery latency | ~50–100 ms | ~1,500 ms |
| Requests/hour/user (idle) | 0 (1 open conn) | ~1,200 |
| Server pattern | Push (event-driven) | Pull (request loop) |
| Best for | Chat, games, live docs | Rarely-changing data |
A solid starter stack
Frontend: React or plain JS with the native WebSocket API. Backend: Node.js + Socket.IO (handles reconnection and fallbacks for you). Store: Redis for presence and pub/sub, Postgres for message history. Stretch goals that impress: typing indicators, delivery receipts, optimistic UI, and horizontal scaling with a pub/sub bridge — each one demonstrates a distinct real-time skill.