I’m building a chat-first community app that uses Bluesky’s AT Protocol for identity.
Current architecture:
- Electron client
- Spring Boot backend (monolith)
- REST for servers/channels
- Planning WebSocket-based messaging
As a solo builder, I’m trying to balance simplicity with future scalability.
At what point would you introduce:
- a separate WebSocket gateway
- pub/sub (Redis, etc.)
- or keep everything in one Spring app until it breaks?
Curious how others approached real-time chat systems early on.
Project for context:
https://github.com/JohannaWeb/ProjectFalcon
I've built multi-channel chat infrastructure and the honest answer is: keep the monolith until you have a specific scaling bottleneck, not a theoretical one.
One pattern that helped was normalizing all channel-specific message formats into a single internal message type early. Each channel adapter handles its own quirks (some platforms give you 3 seconds to respond, others 20, some need deferred responses) but they all produce the same normalized message that the core processing pipeline consumes. This decoupling is what made it possible to split later without rewriting business logic.
On Redis pub/sub specifically: for a solo dev, skip it until you actually have multiple server instances that need to share state. A single process with WebSocket sessions in memory is fine for early users. The complexity cost of pub/sub isn't worth it until you need horizontal scaling or have a separate worker process pushing messages.
What's your current message volume like? That usually determines timing better than architecture diagrams.
reply