A scalable, production-ready chatroom system built with WebSockets, Redis, and Docker.
Supports real-time messaging, room management, and admin controls with horizontal scaling capabilities.
- Overview
- Features
- Architecture
- Technology Stack
- Quick Start
- Performance
- API Endpoints
- Security
- Contributing
- License
ChatRoom is a horizontally scalable real-time messaging platform that supports unlimited concurrent users across multiple chat rooms. Built with a microservices architecture, it features automatic resource management, comprehensive admin controls, and zero data leakage through intelligent cleanup mechanisms. What are WebSockets?
WebSockets provide full-duplex communication between client and server over a single TCP connection. Unlike traditional HTTP requests:
- Persistent connection - eliminates the need to reconnect for each message
- Real-time bidirectional - both client and server can send data at any time
- Low latency - ideal for chat applications, gaming, and live updates
- Efficient protocol - minimal overhead compared to HTTP polling methods
- Real-time Messaging - Sub-50ms message delivery across all connected clients
- Dynamic Room Management - Create/join/leave rooms with automatic cleanup and unlimited capacity
- User Management - Unique client IDs (10000-99999) with customizable usernames
- Automatic Cleanup - Zero memory leaks with TTL-based expiration and intelligent resource management
- Message Broadcasting - Cross-container message propagation with UUID-based loop prevention
- Multi-container Scaling - Horizontal scaling with Redis coordination supporting 10,000+ users per instance
- Dual-Layer Rate Limiting - Infrastructure-wide sliding window (20 req/min) + per-container token bucket protection
- Health Monitoring - Comprehensive heartbeat system with automatic dead connection cleanup
- Admin Dashboard - Complete control over system resources with real-time statistics and management APIs
- Retry Mechanisms - Intelligent message retry (5 attempts, 5-second intervals) with exponential backoff
- Event-Driven Architecture - Custom TypeScript event dispatchers with strongly-typed message handling
- Unique ID Assignment - Automatic generation with collision prevention on connection
- Username Customization - Real-time display name changes with instant broadcast to room participants
- Single Room Policy - Automatic departure from previous room when joining new one
- Connection Resilience - Automatic reconnection with state preservation and message queue replay
- Ban Protection - Special ban code handling with automatic retry mechanism reset
- Instant Room Creation - Generate rooms with custom names up to 16 characters
- Unlimited Capacity - No restrictions on room participant count with efficient Redis Set management
- Auto-Deletion - Automatic room cleanup when last user leaves, preventing orphaned data
- Cross-Container Sync - Real-time room state synchronization across all backend instances
- Room Statistics - Track creation time, active users, message counts, and participant history
Service Mesh Pattern with Redis Coordination
Frontend Layer - Static HTML/CSS/JS with custom state management and retry mechanismsLoad Balancer - Nginx reverse proxy with WebSocket upgrade support and health checks
Backend Cluster - Multiple Node.js instances with WebSocket servers and admin APIs
Data Layer - Redis for state management, pub/sub coordination, and rate limiting
| Backend | Node.js, TypeScript, Express.js, WebSocket (ws) |
| Frontend | Vanilla JavaScript, TypeScript, Tailwind CSS |
| Database | Redis (state management, pub/sub, rate limiting) |
| Infrastructure | Docker, Docker Compose, Nginx |
| Security | JWT Authentication, Dual-layer Rate Limiting |
| Build Tools | esbuild, Tailwind CLI, tsc-alias |
Docker and Docker Compose installed Git for repository cloning
Local Development
# Clone the repository
git clone git@github.com:AnkitBorude/chatRoom.git
#open repo
cd chatRoom
# Set up environment variables
touch .env
# Edit .env with your configuration
#Build and start the application
docker-compose up --build
#Access the application
#Frontend: http://localhost
#Admin API: http://localhost/admin
#Health Check: http://localhost/api/health| Concurrent Users | 10,000+ per backend instance |
| Message Throughput | 50,000+ messages/second |
| Response Time | <50ms average |
| Memory Usage | ~200MB per backend instance |
| Scaling | Tested up to 10 backend instances |
*All this performance metrics are theoritical, not yet load tested
WebSocket Events
Client Events
- JOIN_ROOM - Connect to existing chatroom
- CREATE_ROOM - Create new chatroom with custom name
- SEND_MESSAGE - Broadcast message to room participants
- UPDATE_USERNAME - Change display name
- LEAVE_ROOM - Exit current room
Server Events
- CONNECT - Connection confirmation with client ID
- ROOM_JOINED - Room entry confirmation with details
- NEW_MESSAGE - Incoming message from participants
- USER_EVENT - User activity notifications
- ERROR - Operation failure notifications
Authentication
POST /admin/login - Admin authentication with JWT token
Response Codes: 200, 401, 400, 429
Management Endpoints
Note: All management endpoints require
Authorization: Bearer <token>header
| Method | Endpoint | Description |
|---|---|---|
GET |
/admin/servers |
Server statistics and container information |
GET |
/admin/client |
Array of all connected client IDs |
GET |
/admin/room |
Array of all active room IDs |
GET |
/admin/room/:id |
Detailed room metadata for specific room |
GET |
/admin/client/:id |
Client metadata for specific client |
DELETE |
/admin/room/:id |
Delete room and remove all clients |
DELETE |
/admin/client/:id |
Remove client and exit from all rooms |
- Infrastructure Level - Sliding window algorithm limiting 20 requests per minute across entire cluster
- Container Level - Token bucket algorithm with 4 initial tokens, refilling 1 token per 5 seconds
- IP-based Protection - Coordinated rate limiting using Redis counters with automatic expiration
- JWT-based Admin Access - Secure token authentication with configurable expiration
- Environment-driven Security - Externalized credentials through environment variables
- Client Banning System - Special ban codes with automatic retry mechanism reset
- Input Validation - Strict length limits and sanitization for all user inputs
- Environment Variables - Admin credentials, JWT secrets, Redis configuration
- Constants Management - Centralized limits for rooms, clients, messages, and timeouts
- Health Checks - Automated service monitoring with configurable intervals
- TTL Management - Automatic data expiration for clients (1 hour) and rooms (67 minutes)
Phase 1: Message Persistence
Apache Kafka integration for message queuing PostgreSQL for chat history storage Message replay functionality for new users
Phase 2: Monitoring & Observability
Prometheus metrics collection Grafana dashboards and alerting Centralized logging with structured formats
Phase 3: Security & Performance
SSL/TLS for WSS and HTTPS connections Advanced rate limiting with user-based policies WebSocket compression for bandwidth optimization
Phase 4: Orchestration
Kubernetes deployment with auto-scaling Blue-green deployment strategies Load testing and performance benchmarking
Contributions are welcome! Please feel free to submit a Pull Request.
Development Guidelines- Follow TypeScript best practices and maintain type safety
- Add tests for new features and bug fixes
- Update documentation for any API changes
- Ensure Docker builds pass before submitting PRs
This project is licensed under the MIT License - see the LICENSE file for details.
Made with ⚡ by Ankit Borude
