chat service
WebSocket chat with <50ms delivery, 2k concurrent users, 1.2k GitHub stars, 30+ student projects.
Project Overview
Socket.io server with Redis Pub/Sub for multi-server scaling.
Technology Stack
Key Features
- Instant messaging
- Typing indicators
- Presence
- History
- Rooms
Design Patterns & Architecture
- Event-driven
- Pub/Sub
- State sync
- Connection pooling
Performance
Ultra-low latency
<50ms delivery
1k+ concurrent
Real-time presence
Technical Challenges
- State consistency
- Connection drops
- Server scaling
Key Lessons & Insights
- Event-driven natural for real-time
- Redis excellent for Pub/Sub
- Connection mgmt critical
The Problem
Pain Point
Real-time hard: HTTP polling (99% empty), WebSockets (complex state). Teams over-engineer (Firebase) or under-build (polling disasters).
Industry Context
Real-time = table-stakes. But platforms over-engineered. Lightweight alternatives rare. Target: small teams (5-50) wanting collaboration.
User Impact
<50ms delivery (vs 500ms polling). Instant typing indicators. Accurate presence. Slack/Discord parity, simpler.
Constraints
- <50ms delivery
- 1k+ concurrent
- Real-time typing
- 5s auto-reconnect
- Presence sync
Our Approach
Solution
Socket.io server: store metadata (user, room, presence). Broadcast via Redis Pub/Sub (multi-server scaling). Disconnect: publish presence. Client: auto-reconnect.
Key Decisions
- Socket.io vs raw WebSockets: fallback + auto-reconnect + events; worth 30kb overhead
- Redis Pub/Sub: enables scaling (~5ms lag acceptable)
- MongoDB history: durable, scales (queries slower, acceptable)
- In-memory presence: fast (<1ms), accurate, auto-expires
Trade-offs
- Memory presence: 1k users = 5mb (10k = 50mb acceptable)
- MongoDB latency: 100-300ms (cache recent in Redis)
- Redis single = bottleneck (Sentinel HA, Cluster sharding)
- Reconnect: 10s inconsistency (acceptable window)
Why Built This Way
Real-time = UX. <50ms perceptible (instant vs 200ms = lag). Socket.io+Redis battle-tested. Simple = fewer bugs. Scaling = add servers + Redis.
Results & Impact
Measurable Outcomes
Product Thinking
Real-time = engagement. Users stay 2.5x longer if instant. Typing indicators = psychological retention.
Value Proposition
30s: 'WebSocket chat, <50ms, scales 1k+, open-source, well-commented.' Recruiters saw: clean code, Redis+Socket.io expertise.
Public Metrics
- 2k concurrent peak
- GitHub: 1.2k stars
- 30+ student projects
- 99.9% uptime
Case Study
Team forked repo for internal tool. Scaled 50→500 users 2mo zero changes (good architecture). Added file sharing, video. Shipped 6 weeks (vs 3mo custom).
Architecture Explained
Clients connect via Socket.io WebSocket (fallback: polling). Receive message → broadcast via Redis Pub/Sub. All servers subscribe → relay locally. MongoDB stores history. Redis caches recent. Disconnect: presence broadcast; 5s auto-reconnect.
Purpose & Vision
Prove real-time doesn't need black-boxes. Simple patterns (Socket.io+Redis+MongoDB) scale.
Clarity & Proof
2k concurrent, 1.2k stars, 30+ student projects, 99.9% uptime. Clarity: 'WebSocket chat; <50ms; open-source; well-documented.' Clean code, diagrams, deploy guide.
Future Improvements
- Video/audio (WebRTC complexity)
- File sharing (documented extension)
- Reactions (planned v2)
- Encryption (E2E complexity)
- Admin dashboard (planned v2)
Interested in working together?
Let's create something amazing. Get in touch to discuss your next project.
Go back to all projectsGo to all blog postsContact