Published on

Athoni I: A scalable Matchmaking System on Kubernetes

Authors
  • avatar
    Name
    Jack Nguyen
    Twitter

Let’s face it: building a matchmaking system for online games is like throwing a dinner party for thousands of people who all want to sit next to their besties... and it’s your job to make it happen. Oh, and while you're at it, make sure the food is served hot, everyone gets along, and there are enough tables for everyone—even when your guest list explodes last minute.

That’s basically what this matchmaking system does, except instead of food, we’re serving players sweet, sweet multiplayer matches. Here's how I built it (and kept it scalable and not a total dumpster fire) using Kubernetes (a.k.a. K8s).

In fact, Athoni used this matchmaking system to match players with the same mastery and levels to play competitive learning games (read more about Athoni).

Table of Contents

Step-by-step

Overview

Overview

Step 1: The Player Shows Up (at Our Party)

Step 1

Imagine a player walking in the door, ready to game. They don’t care about our fancy architecture—they just want to join a match. That’s where the Load Balancer (LB) comes in. It’s like our party bouncer, making sure no single server gets overwhelmed.

Once the player gets past the bouncer, they connect to one of our WebSocket servers. These servers are our chatty party hosts, sending real-time updates like, “Hey, your match is ready!” or “We’re still working on it—grab a drink.”

Step 2: Matchmaking Magic

Step 2

Here’s where the real fun begins. Our Matchmaking Service is like a party organizer on steroids, using in-memory priority queues (read: fancy internal lists) to find compatible players.

How it works: 1. Player asks for a match through the API Gateway (think of this as our event registration desk—it checks your ID and makes sure you’re legit). 2. Matchmaking Service pairs players based on compatibility. (You love cats? Me too! Let’s play!) 3. It picks the best game server for the match. But what if all the servers are busy? Don’t worry; we’ll spin up more.

Step 3: Finding a Game Server (or Making One)

Step 3

Coordinate Service = The Party Planner
This is the brains behind the operation. It keeps track of:

  • Which servers are free
  • How many players each server is handling
  • The rules for matchmaking

If it sees a server is overloaded (or all servers are busy), it waves at Kubernetes and says, “Hey, we need another game server pod immediately.” K8s, being the helpful assistant it is, spins one up.

Implementation Choices:

  • If you’re fancy, use Zookeeper (great for managing distributed systems).
  • If you’re scrappy, use Redis with Pub/Sub (think walkie-talkies for your services).

Step 4: Real-Time Notifications and Match Updates

Step 4

We don’t leave our players hanging. As soon as the match is made:

  1. The Event Broker publishes the good news: “Room 101 is ready! Join at this IP and port.”
  2. The WebSocket server tells players, “Hey, your match is ready—go there now!”

From here, players connect directly to the game server. No middlemen. No delays. Just pure, low-latency gaming goodness.

Step 5: Game On (and What Happens After)

Step 5

Now the players are connected to the Game Server and having a blast. What happens next?

  • Once the game ends, the server sends the results to the Result Service, which updates rewards, scores, and anything else important in the database.
  • All updates are wrapped in a single, fail-proof transaction (because losing someone’s high score is a crime in gaming).

Why This System Rocks

  1. Scalability That’s Chef’s Kiss:
    Thanks to Kubernetes, we can add more servers when needed. Big player spike? No sweat.
  2. Real-Time Matchmaking:
    Players are matched fairly and quickly using priority queues. No one’s left standing awkwardly by the punch bowl.
  3. Low Latency = Happy Players:
    Direct WebSocket connections mean fast, smooth gameplay without laggy interruptions.
  4. Failsafe Systems:
    Redis keeps track of players, and our database updates are bulletproof. No lost data here.

Workflow in a Nutshell

If you scrolled straight to this part, here’s the TL;DR:

  1. Player joins through the Load Balancer and WebSocket server.
  2. Matchmaking Service finds compatible players.
  3. Coordinate Service picks (or spins up) a game server.
  4. Players connect directly to the game server.
  5. Game results get processed, rewards get handed out, everyone’s happy.

Closing Thoughts

This matchmaking system isn’t just scalable—it’s built to handle chaos, spikes in players, and the unpredictability of online gaming. With Kubernetes as the backbone, Redis for quick data management, and a well-orchestrated team of services, this system is ready to host the biggest gaming party out there.

If only throwing a real-life dinner party were this smooth.

Discuss on Twitter