Files
docs/adr/015-single-server-sqlite-deployment.md
T
ksv741 cead9dc176
Docs security / security (pull_request) Successful in 6s
Docs verify / verify (pull_request) Successful in 11s
Conventional commits / commits (pull_request) Successful in 11s
Docs security / security (push) Successful in 7s
Docs verify / verify (push) Successful in 10s
docs: document container deployment and recovery
2026-09-16 09:41:58 +03:00

3.2 KiB

015. SQLite в ограниченном single-server deployment

Status: Accepted

Context

ADR 001 ограничивал SQLite локальным MVP. Контейнерная поставка требует постоянного хранилища на одном сервере, но не требует высокой доступности или нескольких экземпляров API. Пользователи, сессии, зашифрованные подключения и банковская история уже хранятся в SQLite. Кэши, limiter и generation подключений локальны процессу.

Decision

Разрешён один backend process на одном Docker host с SQLite в постоянном host directory. Development использует отдельный named volume. SQLite остаётся embedded library без сетевого порта. Это расширяет deployment boundary ADR 001; его исторический контекст сохраняется.

Prisma migrations выполняются отдельным одноразовым service из того же image, что и backend. Перед изменением схемы backend останавливается, всё data directory копируется вместе с возможными WAL/SHM files. Ключ шифрования сохраняется отдельно. Неуспешная migration блокирует запуск новой версии.

Откат image требует совместимости с текущей схемой и не восстанавливает старую базу. Restore требует отдельного решения о потере данных после backup. Frontend и backend имеют независимые версии; production фиксирует version tags. Краткий простой допустим.

Alternatives

PostgreSQL потребовал бы миграции данных и отдельного database lifecycle; текущие требования этого не оправдывают. Kubernetes, replicas и blue-green не устраняют ограничения process-local состояния и не входят в решение.

Consequences

Сервер не обещает HA или zero-downtime. Один backend instance — обязательное ограничение, а не рекомендуемая настройка масштабирования. Нужны контроль свободного места, согласованные backups и проверяемое восстановление.

Решение пересматривается при необходимости нескольких replicas, другом availability target, заметном write contention или потребности в отдельном database service. Добавление реплик до такого решения недопустимо.

Топология описана в архитектуре, операции — в runbook.