Нефункциональные требования
Мы рассмотрели, как проектировать Базу, а теперь пора уделить время нефункциональным требованиям нашей библиотечной системы. Подумаем, что учесть и как обечпечить те характеристики, которые описываются в нефункциональных требованиях.
Рассмотрим следующие характеристики:
1. Производительность
2. Надежность и Доступность
3. Безопасность
4. Масштабируемость
5. Удобство использования и Совместимость
6. Тестируемость и Поддерживаемость

♻️ 1. Производительность ♻️

Требования
• Время отклика:
– Большинство операций (поиск книги, оформление выдачи, возврат) должны выполняться менее чем за 2 секунды.
– Операции формирования сложных отчетов (например, за год) могут занимать до 30 секунд.
• Пропускная способность:
– Система должна выдерживать пиковую нагрузку до 50 одновременных операций (например, в часы "наплыва" читателей перед закрытием или в выходной день).
• Масштабируемость:
– Система должна иметь возможность масштабирования для обслуживания большего количества филиалов или пользователей без полной переработки архитектуры.

Способы исполнения
• Паттерны:
– Кэширование (Caching): Использование кэша (например, Redis или Memcached) для часто запрашиваемых и редко изменяемых данных: список популярных книг, информация о читателях (при частом обращении), справочники (жанры, авторы).
– Пагинация (Pagination): Все списки (результаты поиска, история выдач) должны возвращаться частями (по 20-50 записей), а не целиком.
– Асинхронная обработка (Async Processing): Для длительных операций (формирование объемных отчетов, рассылка уведомлений о задолженностях) использовать асинхронные задачи (через RabbitMQ, Kafka или Celery). Пользователь получает уведомление о готовности отчета, а не ждет его генерации в основном потоке.
• Инструменты:
– База данных: Выбор производительной СУБД (PostgreSQL или MySQL), создание индексов, о которых говорили ранее.

🎲 Расчеты
– Оценка нагрузки: Предположим, в библиотеке 10 активных библиотекарей. Каждый совершает 1 операцию в минуту в спокойном режиме и до 5 операций в минуту в пиковом. Итого: 10 * 5 = 50 операций/мин (≈ 0.83 ops/sec). Это скромная нагрузка, поэтому внимание можно уделить простоте реализации и поддерживаемости системы.
Никаких особенных подходов не требуется для обеспечения такой нагрузки, но можно добавить:
- Нужно оптимизация SQL-запросов
- Рекомендуется использовать простую архитектуру
- Полезно иметь систему мониторинга основных метрик (CPU, память, запросы к базе данных). Это позволит оперативно реагировать на изменения нагрузки или появление узких мест.
Подробнее о RPS поговорим позже.