Where the Leaderboard Runs

ChessHop has two services: the player service and the game service. The leaderboard could run in either one, or in a service of its own. Let’s consider each.

In the player service

The player service already serves profiles, and a profile shows the player’s ranks. It already reads the player database. So putting the leaderboard here looks natural.

But the leaderboard adds a load of its own. At the peak, 100,000 pages of the leaderboard are open. Those requests would go to the same instances that handle accounts and profiles, and they would compete with the requests for accounts and profiles. We also could not add instances for one without adding them for the other. If the leaderboard needs more instances, the player service gets more instances, even if its own work does not need them.

In the game service

The game service computes the new ratings when a game ends. So it knows about every rating change as it happens. That looks useful for a leaderboard that must show changes in real time.

But the requests for leaderboard pages would then go to the instances that run live games. A slow or failing leaderboard could slow down or stop games. The availability requirement says a failure of the leaderboard must not stop games. So the leaderboard cannot run in the game service.

In a service of its own

I choose a service of its own: the leaderboard service. It runs as several instances behind the gateway. The reasons are the ones we gave for the deployment boundary around a monolith:

• Failure. A failure of the leaderboard stays inside the leaderboard service. Games go on. That is what the availability requirement asks for.
• Change. The leaderboard service is released on its own. A change to the leaderboard does not mean releasing the player service or the game service.
• Capacity. The leaderboard’s page views are a different load from accounts, profiles, and games. The leaderboard service can grow on its own.
• Ownership. One team can own the leaderboard service and its data. No other service reads or writes the leaderboard’s data.

graph TD
    C[Clients: website, apps] --> G[Gateway]
    G --> PS[Player service]
    G --> LS[Leaderboard service]
    G -.->|WebSocket| GS[Game service]
    PS --> PDB[(Player database)]
    GS --> PDB

The gateway sends requests whose path starts with /leaderboards to the leaderboard service.