1.8 KiB
1.8 KiB
Why
The platform currently uses in-memory repositories and in-memory log buffers, so users, sessions, jobs, server state, artifacts, and logs disappear when the platform process restarts. Hundreds or thousands of game servers also make row-per-log-line relational storage a poor default: platform metadata needs a durable database, while log bodies need append-friendly segmented storage with bounded cursor reads.
What Changes
- Add configurable durable platform storage so the default local platform process no longer depends on volatile in-memory repositories.
- Add a local file-backed metadata store for immediate durable operation without external database credentials.
- Add a segmented log body store that persists log entries by stream and segment on disk, keeping log query semantics and duplicate detection intact.
- Update platform startup configuration to choose memory or durable local storage with explicit data/log paths.
- Document that MySQL/PostgreSQL-style databases are appropriate for platform metadata and log indexes, while high-volume log bodies should use segmented object/file storage or a purpose-built log backend such as ClickHouse/Loki/OpenSearch in later changes.
Capabilities
New Capabilities
durable-platform-storage: Platform metadata and log bodies survive process restarts through configurable durable storage backends.
Modified Capabilities
- None.
Impact
- Affected backend areas:
platform/config,platform/repo,platform/service,platform/api,platform/cmd/platform,platform/protocol. - No frontend page changes.
- No external paid services, real database credentials, or network downloads are required for this implementation.
- Future MySQL or analytics log backends can be added behind the new storage boundaries without exposing raw host paths, credentials, or direct sockets to plugins or the frontend.