Skip to content

Cloudflare Architecture Direction

Core Principle

The backend should be authoritative and timer-driven. Do not build a constant live-simulation server unless the design changes away from async play.

  • Workers: frontend hosting, API routing, request validation, auth glue.
  • D1: persistent relational game data.
  • Durable Objects: serialized coordination for shared state.
  • KV: cached read models and public summaries.
  • R2: SVG assets, sound, and static content.
  • Queues or alarms: deferred settlement, expirations, and background work.

Durable Object Candidates

  • player session coordinator
  • group expedition instance
  • market or auction house per region
  • guild treasury or guild state coordinator
  • town governance controller

The guiding rule is to create one coordinator per contention boundary instead of one giant global object.

Cost-Safe Simulation Model

Store the following server-side:

  • action type
  • actor set
  • start time
  • end time estimate
  • seed or deterministic inputs
  • risk modifiers
  • supply usage rules

When the player checks in or the action settles, compute the outcome from authoritative state. This avoids expensive per-second simulation.

Data Domains

Likely relational domains include:

  • accounts and characters
  • inventories and item instances
  • recipes and professions
  • markets and orders
  • contracts and escrow
  • regions, areas, and sites
  • codex knowledge
  • guilds and towns
  • audit logs

Rejected Direction

Do not start with real-time open-world combat, large shared map combat loops, or fully synchronous party action. Those drive complexity and cost in exactly the wrong direction for the product goals.