Advanced Project: Real-time Microservice
The capstone: design and build one coherent live-leaderboard service that survives real traffic and scales past a single process.
EventEmitter, async I/O, environment config, SQL, and testing -- now comes together in a single deployable unit. We will build a real-time leaderboard microservice: players submit scores over HTTP, the service ranks them instantly, and every connected client sees the top of the board update live over a WebSocket -- even when the service runs as several containers behind a load balancer.
- draw the architecture of a real-time service and justify each moving part;
- use a Redis sorted set as a fast ranking cache in front of a durable SQL source of truth;
- push live updates to browsers with a WebSocket gateway;
- fan those updates across multiple instances with Redis Pub/Sub;
- reason about the trade-offs -- volatility, at-most-once delivery, coalescing -- honestly;
- package the whole system with Docker Compose and shut it down gracefully.
1. What we are building
A leaderboard service for an online game. It has three jobs, and the interesting engineering is in doing all three at once, correctly:
- Ingest a score:
POST /scoreswith a player and a value. This must be durable -- a crash may not lose a submitted score. - Rank quickly: return the current top 10 in constant, sub-millisecond time no matter how many players exist.
- Broadcast live: every browser watching the board sees the new ranking within a fraction of a second, without polling.
A "microservice" simply means this is one service with one clear responsibility (the leaderboard), talking to its own data stores, deployable on its own. It does not try to also be the auth server or the matchmaking service -- those are separate units it could call.
Why not just a SQL query? You could answer "top 10" with SELECT ... ORDER BY score DESC LIMIT 10. That works at low traffic. But at thousands of writes per second, sorting a growing table on every read, and pushing fresh results to thousands of live sockets, is exactly where a naive single-process design falls over. The rest of this topic is how professionals avoid that.