Server v2 Overview

AT1AS Server v2 is a ground-up rewrite of the backend in Rust: an authoritative, server-side simulation for a 2D space MMO. v2 trades the v1 Swoole/PHP stack for a Rust core built for high-throughput simulation, low-latency networking, and predictable memory behavior.

Status: scaffolding. This document describes the target architecture, not the current state.

Why Rust

The simulation core is CPU-bound and latency-sensitive. Rust gives us fearless concurrency, no GC pauses mid-tick, and tight control over memory layout — which matters when a single sector is stepping thousands of ships per frame. It's a strong fit for:

• Ship movement & physics-ish integration
• Fleet AI (captain/fleet command resolution)
• Mining simulation
• Combat math (threat, intercept, PDC/evade)
• Sector servers (the live game loop)
• WebSocket gateways
• Pathfinding

Stack

Concern	Choice	Role
HTTP + WebSockets	Axum (Tokio)	Public API surface & client transport
Async runtime	Tokio	Everything async
Source of truth	PostgreSQL	Durable world state, accounts, economy
DB access	SQLx	Compile-time-checked queries
Cache / online state	Redis	Sessions, presence, hot lookups
Service events	NATS	Service-to-service messaging
Analytics	ClickHouse	Event log, telemetry, time-series

Axum is the default; Actix is an acceptable alternative if a service needs its actor model. Pick one per service, don't mix within a service.

Workspace layout

A Cargo workspace, one crate per bounded service:

at1as/
  gateway/        WebSocket connections — client fan-in/fan-out
  auth/           login / session issuance
  sector-server/  live game simulation (one process per sector)
  fleet-ai/       captain & fleet command resolution
  economy/        markets / orders / settlement
  persistence/    batched database writes (the only path to Postgres)
  telemetry/      ClickHouse event logging

Shared types (coordinates, entity IDs, wire protocol) live in a common/ crate that every service depends on.

The live game loop

Each sector is a single Rust process that owns all of its state:

• One sector owns its ships, NPCs, and resources.
• Players send commands (intents), never authoritative state.
• The server simulates the result and is the sole authority.
• State is periodically snapshotted to Postgres.

player command ──▶ sector-server (in-memory sim) ──▶ broadcast to clients
                          │
                          └─ every few seconds / on important events ─▶ snapshot

Memory first — the cardinal rule

Do not let every ship write to Postgres constantly. That was the scaling wall in earlier designs.

Rust sector server (memory = working set)
        │
        │  every few seconds, or on important events
        ▼
PostgreSQL (snapshots + event log)

• The simulation runs entirely against in-memory state.
• Writes are batched and flushed by the persistence service on an interval or on significant events (docking, trade settlement, death, ownership change).
• Redis holds volatile online/presence state that doesn't need durability.
• High-volume events go to ClickHouse, not Postgres.

This keeps the tick hot loop free of database round-trips.

Data flow

          ┌────────────┐      ┌──────────┐
clients ──┤  gateway   ├──────┤   auth   │
          └─────┬──────┘      └──────────┘
                │ commands
                ▼
        ┌───────────────┐   NATS   ┌───────────┐
        │ sector-server ├─────────▶│ fleet-ai  │
        │   (per sector)│◀─────────┤  economy  │
        └───────┬───────┘          └───────────┘
                │ batched writes / events
        ┌───────▼───────┐        ┌────────────┐
        │  persistence  ├───────▶│ PostgreSQL │
        └───────────────┘        └────────────┘
                │ events
        ┌───────▼───────┐        ┌────────────┐
        │   telemetry   ├───────▶│ ClickHouse │
        └───────────────┘        └────────────┘

Roadmap

• Cargo workspace + common/ crate (coords, IDs, wire protocol)
• gateway — WebSocket accept loop + client session
• auth — login/register, session tokens in Redis
• sector-server — single-sector tick loop with in-memory entities
• persistence — batched snapshot writer (SQLx → Postgres)
• fleet-ai — command resolution over NATS
• economy — order book + settlement
• telemetry — ClickHouse event sink
• Multi-sector orchestration & handoff

Relationship to v1

v1 (the Swoole/PHP server) remains the live system. v2 is a clean reimplementation of the same authoritative-simulation concept with the same north star: one authoritative world server, players send intents, the server simulates. v2 is not a port — it's a redesign around the memory-first, per-sector-process model.

Next

See the API Reference for the REST surface, and Running Locally to bring the stack up.