Game Server Startup Readiness And Registration

Purpose

Game-server startup assembles the online authority process: config, catalogs, network listeners, database readiness, Redis, realtime workers, encounter state, reconciliation, HTTP routes, control-plane registration, and graceful shutdown. This page explains the order so new startup work lands in the right phase.

Boot Order

Startup loads config, opens DB/Redis connections, checks schema readiness, loads authored/runtime catalogs, builds realtime state, starts durable workers, prepares network endpoints, builds HTTP routes, reconciles stale presence/session state, registers with the control plane, and then serves traffic.

Adding Startup Dependencies

Add a dependency to startup only when normal runtime cannot operate without it. Put schema requirements in schema readiness, background recovery in worker startup, service discovery in registration, and stale state cleanup in reconciliation. Keep optional features degraded but observable.

Readiness And Health

/health reports process liveness. /ready checks draining state, database access, schema readiness, and Redis. /metrics adds runtime details such as session lifecycle journal depths so operators can detect a process that is alive but not safely handling work.

Registration And Shutdown

Control-plane registration should advertise only endpoints that are actually usable. Shutdown should deregister or mark the instance unavailable, stop accepting new sessions, drain or preserve durable work, and leave retryable state in durable queues.

Failure Playbook

Missing catalogs or broken scene/encounter data should fail before normal runtime. Missing migrations should be repaired through login migrations and schema readiness. Redis failures usually block readiness or durable cleanup. Stale presence should be handled by startup reconciliation, not manual key deletion unless the admin runbook calls for it.