Overview
Storm Chat is a real-time messaging platform — think Slack or Discord — built as a team project during my studies. The brief set two hard targets: 100,000 simultaneous connections and 500,000 messages per second, on a €700 infrastructure budget. We didn't hit either target in the end, but the backend is split into microservices, and we built a React + TypeScript frontend on top of it.
Stack choices
- Microservices architecture — the backend is split into independently deployable services (message, room, user, etc.), which pairs well with the chaos-engineering side of the brief: services can be scaled, killed, or redeployed independently without taking the whole system down.
- Go for the backend services — its lightweight goroutines and low-latency scheduler suit holding large numbers of concurrent WebSocket connections without the overhead of a thread-per-connection model.
- NATS was picked as the message broker for inter-service communication, but we never actually got it wired in — services ended up talking to each other directly instead.
One of the clearer mistakes in hindsight: it sat in the stack without doing the job it was meant for. - PostgreSQL handled user accounts, auth, and room/channel management, while ScyllaDB stored the messages themselves — a wide-column store built for very high write throughput and low read latency at scale, which fits a chat system's append-heavy, time-ordered access pattern.
The choice itself held up well; deploying it on Azure was the hard part, and it ate into time we'd planned to spend on load testing. - Redis for caching — presence/online status and hot lookups that don't need to round-trip to the database on every request.
- React + TypeScript for the frontend — the client interface for the messaging app.
- Kubernetes on Azure, provisioned with Terraform, for orchestration and infrastructure as code.