Services and authority
Normalize the boundaries without pretending every state belongs to the same store.
| Component | Responsibility |
|---|---|
| Game client | Interaction, rendering and previews |
| Bridge | Public HTTP authentication, validation and request acceptance |
| World | Live world simulation and authoritative session state |
| Communicate | Realtime communication |
| Internal API | Central contract query/broadcast access and internal operations |
| Internal Worker | Background jobs, outbox processing and signer transactions |
| Admin | Operator input and administration |
Requests and background work
The main synchronous chain path is client → Bridge → Internal API → Gnoland. Background work flows through database outbox and Kafka to Internal Worker, then Internal API. Do not bypass this ownership just because two services can reach the same dependency.
Storage is purpose-specific
PostgreSQL stores persistent game records and definitions. Redis supports runtime coordination and checkpoints. Chunk persistence also uses outbox processing and Garage object storage. Gno contracts own the chain-backed state assigned to them.
Ordinary inventory changes and transaction-sensitive operations have different persistence timing. A client animation is not a commit; a queued chain request is not final confirmation. Crash recovery guarantees must be tested at the owning boundary.
Error boundaries
Use the normalization contract for safe public problems and separate private diagnostics. Transport failures, command rejection and application failures remain distinct.