The situation
A high-concurrency multiplayer VR platform needed a notification system to push timely messages to large numbers of connected users, across regions, without destabilising the platform it plugged into.
What actually needed solving
The system had to deliver low-latency notifications with authentication, standardised message formats, connection limits, keepalive and health behaviour, feedback on undeliverable messages, multi-region operation, autoscaling, and observability, while being realistic to build and operate within the existing platform and timeline.
What I had to work within
- High concurrency with real latency and scale expectations
- Multi-region operation and autoscaling from the outset
- An existing platform whose shape the design had to respect
- A delivery timeline that ruled out the most elaborate options
How I moved it forward
- 01
Explored several architectures (managed WebSockets, serverless components, queues, DynamoDB, long polling, and Redis) against the platform's real constraints.
- 02
Weighed each against latency, scale, failure modes, and operational cost rather than novelty.
- 03
Selected a long-polling and Redis proof of concept that fit the existing platform and could be delivered and operated realistically.
- 04
Built the design around observability and clear failure behaviour, including feedback for undeliverable messages.
The trade-offs that mattered
Pragmatism over fashion
The most complicated architecture is rarely the right one. Long polling plus Redis met the requirements and fit the team and platform that had to run it.
Design failure modes explicitly
Keepalive, health, connection limits, and undeliverable-message feedback were first-class concerns, not afterthoughts.
Prove it with a focused PoC
A proof of concept validated the approach against real constraints before committing to a full build.
What changed
- A pragmatic, operable design validated by a working proof of concept.
- An architecture matched to the platform's real constraints rather than to trend.
- Clear reasoning that let stakeholders trust the trade-offs made.
What I took from it
- Choosing the right solution often means declining the most impressive one.
- Latency, scale, and failure modes are design inputs: decisions made without them are guesses.