Skip to content

0001 — Use multi-regional architecture

Stub. This ADR is a placeholder. Fill it in from chat history with the team — the decisions, alternatives weighed, and consequences should be reconstructed from the original discussion. Once filled, change Status from "Stub" to "Accepted" and update ADR/README.md's index.

Status

Stub — to be backfilled by the team.

Context

(Stub — fill in from chat history.)

The game universe is structured into multiple regions (Central Nexus, Terran Space, and player-owned regions of 100–1,000 sectors), each with their own governance, citizenship, and infrastructure characteristics. The team chose to model this as a first-class architectural concern rather than as a single flat universe with tags or scopes.

Questions to answer in this section when filling it in:

  • What pressures (gameplay, monetisation, scaling, governance) led to this shape?
  • What single-region or flat-universe alternatives were considered?
  • What constraints did the team commit to (e.g. cross-region traffic via a dedicated redis-nexus instance, citizenship as a subscription, owner-controlled governance)?

Decision

(Stub — fill in from chat history.)

The game runs as a multi-regional system in which:

  • Regions are first-class entities with their own identifier, type (central_nexus / terran_space / player_owned), zone layout, and governance settings.
  • Cross-region presence and movement is mediated through dedicated infrastructure (e.g. redis-nexus for cross-region pub/sub, see OPERATIONS/realtime.md and SYSTEMS/realtime-bus.md).
  • Region ownership and citizenship are subscription-funded ($25/month and $5/month respectively).
  • Region owners control governance: taxes, PvP rules, citizenship requirements, treaties.

When filling this in, list the specific decisions the team made — and the alternatives they explicitly rejected — so readers can see the shape of the choice, not just the outcome.

Consequences

(Stub — fill in from chat history.)

Positive:

  • (stub — e.g. governance flexibility, monetisation surface, natural sharding)

Negative:

  • (stub — e.g. operational complexity of cross-region infrastructure, design overhead for every cross-cutting feature)

Neutral:

References