Instant Messaging Platform
A real-time messaging application built using Spring Boot, WebSocket, Redis Pub/Sub, and React, supporting instant communication, authentication, and scalable message delivery.
I wanted to understand how apps like WhatsApp or Slack actually deliver messages instantly, instead of the browser constantly asking the server "anything new yet?" That question is basically what started this project. Once I looked into it, it came down to two ideas — WebSockets for keeping a live connection open, and a message broker like Redis for making sure that connection scales past a single server. So I set out to build a chat app that actually uses both properly, rather than faking real-time with aggressive polling.
The feature list looks fairly standard for a chat app:
But the interesting part for me wasn't the feature list, it was making all of that feel instant.
I used Spring's WebSocket support along with STOMP to set up persistent connections between the client and server. Once that connection is open, messages just get pushed through immediately, no repeated requests, no polling delay.
The trickier problem showed up once I started thinking beyond a single server. If the app ever ran on multiple instances, a message sent through one instance wouldn't reach a user connected to another. That's where Redis Pub/Sub came in — it broadcasts messages across instances so everyone gets them regardless of which server they're connected to. It's a small addition on paper, but it's the difference between something that works in a demo and something that could actually scale.
Since WebSocket connections stay open for a long time, I made sure they went through the same JWT-based authentication as the rest of the app, with proper user validation before a connection is even accepted. Every messaging endpoint sits behind that same layer, so there's no gap where the real-time part is less protected than the regular REST API.
The backend follows the same layered approach I tend to default to now — controllers, services, repositories, with security and WebSocket configuration handled separately. MySQL stores the persistent stuff: users, conversations, messages, and chat rooms. Redis, meanwhile, only deals with the short-lived, in-the-moment messaging events.
This was my first real dive into event-driven systems, and it changed how I think about backend design in general — not everything has to be a request-response cycle. I came away with a much better grasp of WebSocket communication, how Redis Pub/Sub solves the multi-instance problem, and what it actually takes to build something real-time instead of something that just looks real-time.