Ludo Game Microservices: Auth, Game, and Matchmaking Services

Monolithic Ludo game servers work well for small player bases, but as your platform grows to thousands of concurrent matches, a microservices architecture becomes necessary to scale each component independently, deploy updates without downtime, and isolate failures so a bug in the leaderboard service does not bring down live game sessions. This guide decomposes a Ludo game platform into distinct services — authentication, game engine, matchmaking, leaderboard, and notification — and demonstrates how they communicate via REST APIs and message queues with practical code examples.

Service Decomposition for Ludo Platforms

The Ludo game platform naturally splits into five independent services, each with its own database, scaling characteristics, and deployment lifecycle. The authentication service handles login, registration, and JWT issuance. The matchmaking service queues players and creates game sessions. The game engine service runs the authoritative game loop, validates moves, and broadcasts state. The leaderboard service aggregates scores and maintains rankings. The notification service sends push notifications and in-game messages.

The key principle is that each service owns its data — no service directly queries another service's database. All cross-service data access happens through APIs or published events. This boundary enables each service to evolve its data model without coordinating schema changes across teams.

Authentication Service

The auth service is the gatekeeper for all other services. It issues JWT tokens containing player ID, account tier, and permissions. Other services validate tokens locally using a shared secret or public key, avoiding a round-trip to the auth service on every request. JWTs expire after 24 hours; refresh tokens with a 30-day lifetime enable seamless re-authentication without prompting the player.

// Auth Service: token issuance and validation
const jwt    = require('jsonwebtoken');
const bcrypt = require('bcryptjs');
const redis  = require('ioredis').default;

const JWT_SECRET    = process.env.JWT_SECRET;
const JWT_EXPIRES   = '24h';
const REFRESH_EXPIRES = '30d';
const client = new redis({ host: process.env.REDIS_HOST });

// POST /auth/login
async function login(req, res) {
  const { email, password } = req.body;

  const player = await db.players.findOne({ email });
  if (!player || !bcrypt.compareSync(password, player.passwordHash)) {
    return res.status(401).json({ error: 'Invalid credentials' });
  }

  const accessToken  = jwt.sign(
    { sub: player.id, username: player.username, tier: player.tier },
    JWT_SECRET,
    { expiresIn: JWT_EXPIRES }
  );

  const refreshToken = jwt.sign(
    { sub: player.id, type: 'refresh' },
    JWT_SECRET,
    { expiresIn: REFRESH_EXPIRES }
  );

  // Store refresh token in Redis with TTL for revocation support
  await client.setex(`refresh:${player.id}`, 30 * 86400, refreshToken);

  await db.players.updateOne({ id: player.id }, { $set: { lastSeenAt: new Date(), isOnline: true } });

  return res.json({
    accessToken,
    refreshToken,
    playerId: player.id,
    expiresIn: 86400
  });
}

// Middleware: validate JWT on all protected routes
function authMiddleware(req, res, next) {
  const header = req.headers.authorization;
  if (!header?.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'Missing authorization header' });
  }

  const token = header.slice(7);
  try {
    const payload = jwt.verify(token, JWT_SECRET);
    req.player = payload;
    next();
  } catch (err) {
    if (err.name === 'TokenExpiredError') {
      return res.status(401).json({ error: 'Token expired', code: 'TOKEN_EXPIRED' });
    }
    return res.status(401).json({ error: 'Invalid token' });
  }
}

// Token revocation (e.g., on logout or account ban)
async function revokeToken(playerId) {
  await client.del(`refresh:${playerId}`);
}
    

Game Engine and Matchmaking Communication

The game engine and matchmaking services communicate asynchronously via Redis streams or RabbitMQ, keeping them loosely coupled. When the matchmaking service finds two players who should play together, it publishes a game.created event that the game engine consumes to initialize a new game session. This decoupled design means the game engine can process games at its own pace without the matchmaking service waiting for it.

// Matchmaking Service: publishes game creation events
const { RedisClient } = require('./lib/redis');
const redis = new RedisClient();

async function createMatch(playerIds, variant = 'classic') {
  const gameId = uuidv4();

  const game = await db.games.create({
    id:        gameId,
    variant,
    players:   playerIds,
    status:    'pending',
    createdAt: new Date()
  });

  // Publish game creation event for game engine to consume
  await redis.publish('ludo:game:created', JSON.stringify({
    gameId,
    playerIds,
    variant,
    createdAt: game.createdAt
  }));

  // Notify each player of their game assignment
  await redis.publish('ludo:notification:send', JSON.stringify({
    type:     'GAME_READY',
    gameId,
    playerIds,
    message:  'Your Ludo game is ready!',
    channels: ['push', 'websocket']
  }));

  return { gameId, status: 'pending' };
}

// Game Engine Service: consumes game creation events
async function startGameEngineConsumer() {
  const subscriber = new redis.createSubscriber();
  await subscriber.subscribe('ludo:game:created');

  subscriber.on('message', async (channel, message) => {
    if (channel !== 'ludo:game:created') return;

    const { gameId, playerIds, variant } = JSON.parse(message);
    console.log(`[GameEngine] Initializing game ${gameId} for players: ${playerIds.join(', ')}`);

    // Initialize game state in Redis
    const initialState = buildInitialState(gameId, playerIds, variant);
    await redis.setex(`game:${gameId}`, 7200, JSON.stringify(initialState));

    // Assign game server based on current load
    const serverId = await assignGameServer();
    await redis.set(`game:${gameId}:server`, serverId);

    // Notify matchmaking service
    await redis.publish('ludo:game:ready', JSON.stringify({ gameId, serverId }));
  });
}

// gRPC or REST — synchronous service-to-service calls
async function getPlayerProfile(playerId) {
  const response = await fetch(`${AUTH_SERVICE_URL}/players/${playerId}`, {
    headers: { 'Authorization': `Bearer ${SERVICE_TOKEN}` }
  });
  if (!response.ok) throw new Error(`Auth service error: ${response.status}`);
  return response.json();
}
    

Service Mesh and Fault Tolerance

In a microservices architecture, network failures between services are not exceptional — they are expected. Implement circuit breakers around inter-service calls so a failing leaderboard service does not cascade and bring down the game engine. A circuit breaker tracks failure rates and, after a threshold is exceeded, opens the circuit and returns cached or default responses for a cooldown period before testing whether the downstream service has recovered.

// Circuit breaker for inter-service calls
class CircuitBreaker {
  constructor(fn, { failureThreshold = 5, resetTimeout = 30000 } = {}) {
    this.fn                = fn;
    this.failureThreshold  = failureThreshold;
    this.resetTimeout      = resetTimeout;
    this.failures          = 0;
    this.state             = 'CLOSED'; // CLOSED | OPEN | HALF_OPEN
    this.nextAttempt       = 0;
  }

  async call(...args) {
    if (this.state === 'OPEN') {
      if (Date.now() < this.nextAttempt) {
        throw new Error('Circuit breaker is OPEN — service unavailable');
      }
      this.state = 'HALF_OPEN';
    }

    try {
      const result = await this.fn(...args);
      if (this.state === 'HALF_OPEN') {
        this.state    = 'CLOSED';
        this.failures = 0;
      }
      return result;
    } catch (err) {
      this.failures++;
      if (this.failures >= this.failureThreshold) {
        this.state     = 'OPEN';
        this.nextAttempt = Date.now() + this.resetTimeout;
        console.warn(`Circuit breaker OPENED after ${this.failures} failures`);
      }
      throw err;
    }
  }
}

// Usage: wrap leaderboard service calls
const fetchLeaderboard = new CircuitBreaker(
  async (variant) => {
    const res = await fetch(`${LEADERBOARD_URL}/rankings/${variant}`);
    if (!res.ok) throw new Error(`Leaderboard error: ${res.status}`);
    return res.json();
  },
  { failureThreshold: 3, resetTimeout: 30000 }
);
    

Data Isolation Between Services

Each microservice maintains its own database schema. The game engine has no direct access to player authentication data — it receives only the player ID and display name from the auth service. If the leaderboard service needs player usernames for display, it subscribes to a player.updated event published by the auth service rather than querying its database directly. This event-driven data sharing prevents tight coupling and enables independent service evolution.

FAQ