Existing stateless web approach

log partitioning, consumer, cache/DB, pub/sub, and presence separately handle per-player ordering and push

Existing stateless web approach log partitioning, consumer, cache/DB, pub/sub, and presence separately handle per-player ordering and push Game Client · Architecture component Game Client Room Field · Architecture component Room Field Load Balancer · Architecture component Load Balancer Event Ingest API · Architecture component Event Ingest API Partitioned Log · Stateless Backend Partitioned Log Quest Consumer · Stateless Backend Quest Consumer State DB · Stateless Backend State DB Read Model · Stateless Backend Read Model Pub Sub · Stateless Backend Pub Sub Presence · Stateless Backend Presence Stateless Backend

Existing composition

  • • A room/field sends gameplay events through a load balancer to an ingest API, which appends to a partitioned log.
  • • A quest consumer reads the log, updates a per-player state DB and read model, and publishes to pub/sub.
  • • Presence subscribes to pub/sub and pushes back to the room/field, which relays to the client.

GameQuest equivalent

  • • GameQuest uses the PlayerId as the global SpotId in the progress tier, leaving the owner turn to the Framework.
  • • QuestEventStore, projection, and reset/reconcile stay with the Application — this is not the Framework providing Kafka durability or reward-payout atomicity.