2. Players Send Intents as Events, Not REST Commands
- Status: accepted
- Date: 2025-02-25 (confirmed 2025-09-05)
- Deciders: Jannik Alexander, Stefan Bente, Daniel Köllgen (governance board)
Context
In MSD 1.0, players send commands as synchronous REST calls, and the Game service collects and dispatches them in rounds. MSD 2.0 is a real-time game without rounds, built as an event-driven microservice landscape. Many player actions (buying a robot, upgrading it, mining) pass through several services, some of which act as “authorizers”: Trading rejects a purchase without enough money, Robot rejects an action the robot is not equipped for.
The board wants the MSD to be as close as possible to a production microservice landscape, with decoupled services and players as full-blown services rather than “second-class citizens”. A player may send many commands for the same robot in quick succession, and they must be processed in order.
Decision
- Players MUST submit in-game commands (controlling robots, trading) as intent events to Kafka. Core services MUST NOT offer REST endpoints for these actions.
- The player lifecycle is not covered: registering a player and joining a game remain REST calls to the Game service.
- An intent expresses what a player wants; the owning service decides whether and when it happens, and publishes the outcome as an event.
- Core services MAY offer read-only REST endpoints as a “plan B” for querying state, outside the regular game flow.
Topics and schemas for intents are defined in ADR-0003.
Alternatives
- REST commands to the owning core service — rejected primarily because the MSD is a study ground for event-driven communication, in which services — and players — are meant to be decoupled. A REST call couples the player to the core service in time: the service must be available and answer while the player waits. Its advantages, a synchronous answer and well-understood authentication, were considered less important.
Consequences
- Good: one communication style for players and core services.
- Good: players learn event-driven integration by doing it, which is the point of the MSD.
- Good: a slow or unavailable core service does not block a player.
- Bad: players get no immediate answer and must correlate outcome and error events with the intents they sent.
- Bad: without authentication on Kafka, a player can publish intents in another player’s name — accepted for now, see ADR-0004.
- Bad: event sequences through authorizing services form implicit sagas; players may end up building their own orchestration logic. The board accepted this knowingly.