About the Microservice Dungeon

What is the Microservice Dungeon?

The Microservice Dungeon (MSD) is a large-scale, distributed application designed as a game. It looks like a strategy game in space: players control fleets of robots, explore maps of planets and space stations, mine resources, trade, and fight each other. But the real purpose is not the game itself. MSD should be a state-of-the-art microservice landscape:

  • Each piece of game logic (robots, map layout & mining, trading, game lifecycle, etc.) is implemented as an independent microservice.
  • Communication happens through events, intents, and asynchronous messaging, very similar to real-world e-commerce or logistics platforms.
  • Players act as internal services that interact with the MSD core services through APIs and events.

In short: MSD is a sandbox where you can experience the challenges of modern software architecture in a safe, playful, but technically realistic environment.

Why does the Microservice Dungeon exist?

Modern software rarely comes as a single monolithic application. Instead, companies run large, distributed systems with dozens or hundreds of microservices. These systems are powerful, but also fragile:

  • What happens if one service goes down?
  • How do we ensure consistency across multiple databases?
  • How do we handle thousands of events per second?
  • How do we scale up and still keep everything observable and secure?

The MSD is designed to simulate these challenges in a controlled environment. It’s here to help people learn and experiment with Microservices:

  • For students, it’s a way to learn by coding, deploying, debugging, and experimenting.
  • For developers in workshops, it’s a way to experience microservice architectures under realistic conditions.
  • For researchers, it’s a platform to study scalability, resilience, observability, and architectural patterns in a controlled but non-trivial environment.

Principles that guide the MSD

  1. As real as possible: MSD resembles a productive microservice landscape (e.g. e-commerce), not just a toy project. Game-specific features are simplified if they conflict with architectural realism.

  2. Fun matters: Learning is easier if it’s fun. MSD is designed as a game with competition and exploration, so participants stay motivated.

  3. Security with pragmatism

    • Outside participants = zero trust.
    • Inside a course = pragmatic trust (errors are mistakes, not attacks).
    • Always apply basic security rules (e.g. DB passwords, API keys).

  4. Sustainable core, experimental edges

    • The core services follow strict guidelines: mainstream technologies, strong guardrails, consistent architecture.
    • On top, students and researchers are free to explore new stacks and ideas.
    • Sandbox experiments must be documented, but don’t need to be merged into the main system.

  5. Simplicity where possible, complexity where needed: Architecture should stay as simple as possible, but not simpler than what real-world systems require.

How does the game work?

The game simulates a 2D universe made of planets, space stations, and hazards like black holes.

  • Robots are the main actors. Each player controls robots that can move, mine, fight, and trade.
  • Planets provide resources, which robots can mine.
  • Space Stations are hubs for spawning robots, trading goods, buying upgrades, and repairing damage.
  • Resources (e.g. Bio Matter, Plasma Cores, Dark Matter) can be mined and sold for money.
  • Trading lets players buy vouchers for robots or upgrades.
  • Fighting allows players to attack each other’s robots for rewards.

You can find the detailed game rules here.