Продолжаем разбирать нефункциональные требования.

♻️ 2. Надежность и Доступность ♻️

📜Требования
✏️ Доступность: Система должна быть доступна 99.9% времени в рабочие часы библиотеки (это чуть более 8 часов простоя в год). Критично, чтобы система не "падала" в часы пиковой нагрузки.
✏️ Целостность данных: Не допускается потеря данных о выдачах, читателях или книгах. Все финансовые операции (начисление/списание штрафов) должны быть транзакционными.
✏️ Восстановление после сбоев: В случае сбоя система должна восстанавливаться из последней резервной копии с минимальной потерей данных (целевой показатель восстановления - RTO < 1 часа, целевой показатель точки восстановления - RPO < 15 минут).

🗂 Способы исполнения

📘 Паттерны:
🔸 Репликация базы данных: Настройка Master-Slave репликации. Slave-реплика может использоваться для чтения (например, для отчетов), а также служить "горячим" резервом на случай падения Master.
🔸 Резервное копирование (бекапы): Регулярное (ежедневное) автоматическое резервное копирование базы данных и файловых Assets (например, сканы документов читателей). Хранение бэкапов не только на основном сервере, но и в удаленном хранилище (например, в облаке Яндекса).


📘 Инструменты:
🔹 Мониторинг: Использование систем мониторинга (Prometheus + Grafana, Zabbix) для отслеживания доступности, нагрузки и потребления ресурсов.
🔹 Балансировщик нагрузки: Например, nginx для распределения запросов между несколькими экземплярами приложения.


📘 Архитектура:
Для обеспечения 99.9% доступности достаточно одной ноды (сервера) приложения и одной ноды базы данных с правильно настроенной репликацией и мониторингом. Переход на отказоустойчивый кластер (например, с несколькими нодами приложения за балансировщиком) потребуется при более строгих требованиях (99.99%).
А про виды девяток и их влияние поговорим немного позже