The problem
A live game platform with millions of player interactions, and players who expect a match the moment they're ready.
Matching had to work in real time, across many separate services. This is employer work, so the page is a summary: what I built and what it changed, without the internals.
- Real time
- No service waits on another
What I built
- Real-time matchmaking I designed it on Redis Streams. Services publish what happens as it happens, and each one reads what it needs, instead of calling another and waiting. Gamer retention rose 30%.
- A faster backend I led an upgrade of the microservices, with Redis batching and optimised schema indexes. Inter-service latency fell 40%, and throughput held up better under load.
- Services at scale Backend services in Node.js and TypeScript, built as microservices, supporting millions of gaming interactions.
How it runs
- Start
- Stored
- Check
- Result
Game services
01, Trigger:
A player is ready
Game services
Joining a match is an event.
Event bus
02, Data:
Onto the stream
Redis Streams
Services publish as it happens, and read what they need.
Matchmaking
03, Logic:
Players matched
Matchmaking service
Grouped in real time, as events arrive.
Game services
04, Output:
Match announced
Redis Streams
Every service that needs it picks it up.
The drawing is generic on purpose. It shows how the parts talk, not what they're called inside.
What I took from it
At scale, services shouldn't wait on each other. Say what happened, and let each one get on with its job.
More on my role
My full record at Metaverse Magna, with the rest of my experience, is on the About page.