Phase 20: Many Machines

This phase is still ahead.

Ships

v1.1.0

Lesson

Distributed systems for games: gateways, service registries, inter-process handoff, partial failure and rolling deploys

Depends on

Phase 19, and an ADR linking a measured single-process limit (see scaling.md)

• Decision Record the measured single-process limit that justifies splitting, the options (more tuning, a bigger host, a gateway plus zone processes) and the choice.

• lorehallow-gateway: terminates client WebSockets, authenticates, and routes each player to a zone process; clients don’t reconnect on handoff.
• Internal protocol between gateways and zone processes in proto/ (package lorehallow.internal.v1), with golden vectors, over one persistent connection per process pair.
• Service registry: which zone runs where, health checks, and draining a zone process before a deploy.
• Cross-process handoff using the Phase 11 protocol, rolling back when either side fails.
• Chat, whispers and parties across processes.
• make server runs the whole set locally; production gets a systemd unit per service.

• Zone processes on a second machine over a private network, with mutual TLS between processes.
• Partial-failure tests: kill a zone process, a gateway, or the network between them; players end up safe and can reconnect.
• Rolling deploys: drain and restart one zone process at a time with no lost progress.

• Re-run every scaling.md case against the split deployment, measure the cost of the extra hop, and record before and after in docs/perf/phase-20.md.

• docs/walkthroughs/phase-20-many-machines.md: gateways, inter-process handoff, partial failure, and what splitting did and didn’t fix.
• Devlog draft, release notes and tag v1.1.0.

• The limit recorded in 20.1 is gone, with before and after results on named hardware.
• A zone process crash affects only its zones’ players, who are back in the world within 30 seconds.
• A rolling deploy across every zone process loses no progress.