Прогресс: hot/cold и Postgres

Уровни (player_level_results, player_level_progress) и GameRun хранятся только в Postgres. Терминальная команда меняет результат в своей транзакции; recompute_progress строит сводку из результатов по проекту, игроку и механике.

Старый событийный контур

Для data/native engine PlayerProgress использует Dragonfly hot cache и долговечную Postgres cold copy. progression.rs читает и гидратирует cache miss, cold_storage.rs пишет базу; sync.rs и jobs/sync_queue.rs синхронизируют hot→cold. Heartbeat worker называется sync; cold_sync_last_success — поле статуса API. Старый snapshot_queue удалён. hot_restore_queue и reconcile восстанавливают отсутствующие hot keys.

При недоступном Dragonfly чтение идёт в Postgres с заголовком X-PlayFlow-Degraded: cold-read; запись ставит hot-restore. Если недоступны оба хранилища — 503 с Retry-After. Критические outcome/level.complete/ session_end сохраняют подтверждённый прогресс синхронно в cold storage.

Цели наблюдения: RPO и p95 sync lag ≤30 секунд, p95 cold→hot <500 мс, p95 hot-read <20 мс. Это цели SLO, а не гарантия каждого запроса.

GameRun

game_run_progress::apply_common_progress пишет player_template_progress непосредственно в транзакции подтверждённого результата. Чтение engine=game_run обходит hot key. Cold reconcile исключает такие строки, а sync defensively отбрасывает старые GameRun-ключи, чтобы не затереть уже подтверждённый результат. Добавлять сюда Dragonfly как источник истины нельзя.

В /v1/status: hot_read_latency_ms, sync_lag_seconds, cold_sync_last_success, dlq_depth, webhook_retry_queue_depth и table_sizes. Доступ — владельцу с подтверждённой 2FA; API.