27 lines
1.8 KiB
Markdown
27 lines
1.8 KiB
Markdown
## 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.
|