Описать нефункциональные требования для высоконагруженной системы

Нефункциональные требования для высоконагруженной системы бронирования билетов

КОНТЕКСТ

• 1 млн активных пользователей
• Пиковая нагрузка: 100,000 одновременных запросов при открытии продаж
• Критична точность данных (не могут быть проданы два одинаковых билета)
• Система должна работать 24/7

---

1. ПРОИЗВОДИТЕЛЬНОСТЬ (Performance)

NFR-101: Время отклика (Response Time)

Требования по типам операций:

Обоснование:

• P50/P95 — для обычной работы пользователя
• P99 — для ненормативных условий (нагрузка близка к максимальной)
• Максимум — критический порог, если превышен → сообщение об ошибке пользователю

Включаемые компоненты: Network latency (в т.ч. CDN), API gateway, приложение, БД, сеть обратно

NFR-102: Пропускная способность (Throughput)

Требования:

• Нормальная нагрузка: >= 1,000 запросов в секунду (RPS)
• Пиковая нагрузка: >= 10,000 RPS при открытии продаж популярного мероприятия
• Максимальная нагрузка: >= 50,000 RPS (при скалировании инфраструктуры)
• Тестирование: Под нагрузкой 100,000 одновременных пользователей

Метрика успеха: % успешно обработанных запросов >= 99.5% при пиковой нагрузке

NFR-103: Задержки при критичных операциях

Time-to-First-Byte (TTFB): <= 100 ms
Page Load Time (общее): <= 2 сек
Interactive UI: <= 1 сек (после начала загрузки)

---

2. МАСШТАБИРУЕМОСТЬ (Scalability)

NFR-201: Горизонтальное масштабирование

Требования:

• Приложение должно быть stateless (без сохранения сеансов в памяти)
• Можно добавлять/удалять серверы без перезагрузки
• Использование Load Balancer (Nginx, AWS ELB) для распределения нагрузки
• Session хранится в Redis, не в памяти приложения

Метрика: При добавлении нового сервера пропускная способность увеличивается линейно (±10%)

NFR-202: Вертикальное масштабирование

БД:

• Индексы на часто используемые поля (user_id, event_id, status)
• Партиционирование таблиц по дате события (каждый месяц — отдельный partition)
• Read replicas для распределения нагрузки на чтение
• Шarding при необходимости (например, по event_id)

Cache слой (Redis):

• Список мероприятий: кэшируется на 5 минут
• Доступные билеты: кэшируется на 10 сек (для баланса между свежестью и производительностью)
• Данные заказов пользователя: персональный кэш на 1 час

Метрика: БД способна обрабатывать >= 50,000 запросов в секунду

NFR-203: Автоматическое масштабирование

Если нагрузка возрастает:

• CPU > 70% на 2 минуты → добавить 1 инстанс приложения
• Очередь задач (Queue) > 10,000 сообщений → добавить воркер
• Connection pool к БД близок к максимуму → алерт администратору

Если нагрузка снижается:

• CPU < 30% на 10 минут → удалить избыточный инстанс (но оставить минимум 2)

---

3. ДОСТУПНОСТЬ (Availability)

NFR-301: SLA (Service Level Agreement)

Целевая доступность: 99.99% (не более 52 минут простоя в год)

Расчёт:

• 99.99% * 365 дней * 24 часа * 60 минут = 52 минуты простоя

Что не считается простоем:

• Плановое техническое обслуживание (планируется в off-peak часы)
• Проблемы у провайдеров платежей (не в нашей ответственности)

NFR-302: Время восстановления после сбоя (MTTR)

Mean Time To Recovery: <= 5 минут

• Автоматическое обнаружение сбоя: <= 30 сек
• Автоматическое переключение на резервные серверы: <= 2 минут
• Проверка здоровья системы и возврат в строй: <= 2 минут 30 сек

NFR-303: Мониторинг и Алерты

Критичные метрики:

• Доступность API: каждые 10 сек проверка с помощью health check
• Error rate: если > 1% → SMS алерт администратору
• Response time: если P95 > 2 sec → Email алерт
• БД replication lag: если > 10 сек → Email алерт

Инструменты:

• Prometheus для сбора метрик
• Grafana для визуализации
• PagerDuty для оповещений критичных проблем

NFR-304: Резервный центр обработки данных (Disaster Recovery)

RTO (Recovery Time Objective): <= 15 минут
RPO (Recovery Point Objective): <= 1 минуты

Реализация:

• Active-Passive: основной DC + резервный
• Синхронная репликация БД между DC-центрами
• DNS failover: при падении основного DC переключить на резервный

---

4. НАДЁЖНОСТЬ (Reliability)

NFR-401: Консистентность данных

Требование: 100% точность в отношении доступных билетов

• Не должны быть проданы 2 билета с одинаковым номером
• Если два пользователя одновременно пытаются купить последний билет — один получит его, другой увидит "нет в наличии"

Механизм:

• Использование optimistic locking или row-level locks в БД
• Атомарная операция: UPDATE tickets SET sold=true WHERE id=X AND sold=false
• При конфликте: откат транзакции, попытка выбрать другой билет

Метрика: Ноль конфликтов с перепродажей в production

NFR-402: Обработка ошибок и Retry logic

Сценарий: Платёж не прошёл на первой попытке

• Retry 1: через 2 сек
• Retry 2: через 5 сек
• Retry 3: через 15 сек
• Retry 4: через 60 сек
• После 4 попыток: откат заказа, освобождение билетов

Сценарий: Сеть недоступна (пользователь в метро)

• Сохранить заказ локально в IndexedDB браузера
• При восстановлении сети — автоматически отправить

NFR-403: Обработка рассинхронизации

场景: Два мероприятия стартуют в один момент времени

• Используется Message Queue (RabbitMQ/Kafka) для управления очередностью заказов
• Гарантия: at-least-once delivery (в крайнем случае — дубль, но не потеря)
• Идемпотентные операции: повторный заказ по same idempotency_key не создаёт дубликаты

NFR-404: Data backup и Recovery

Резервные копии:

• Полная резервная копия: 1 раз в день (в 3:00 UTC, off-peak время)
• Инкрементальная резервная копия: каждый час
• Хранение: 30 дней
• Место: географически отдельный регион (для защиты от катастроф)

Тестирование восстановления: 1 раз в месяц проверять, что recovery работает

---

5. БЕЗОПАСНОСТЬ (Security)

NFR-501: Аутентификация и Авторизация

Аутентификация:

• Email + пароль (минимум 8 символов, complexity rules)
• Двухфакторная аутентификация (2FA) опционально
• Сессия: JWT токен с TTL 24 часа

Авторизация:

• User может видеть только свои заказы
• Admin может видеть все заказы и управлять мероприятиями
• Сотрудник call-center может видеть все заказы (для поддержки)

NFR-502: Защита от атак

SQL Injection:

• Использование parameterized queries везде
• ORM (SQLAlchemy) предотвращает SQL injection по умолчанию

DDoS:

• Rate limiting: максимум 10 запросов в секунду с одного IP
• API Gateway блокирует подозрительный трафик
• Cloudflare DDoS protection

Credential stuffing (подбор пароля):

• Максимум 5 неудачных попыток входа → блокировка аккаунта на 15 минут
• Логирование подозрительных попыток входа

Man-in-the-Middle (MITM):

• Обязательно HTTPS (TLS 1.3+) для всех соединений
• HSTS header: пользователь всегда использует HTTPS
• Certificate pinning в мобильном приложении

NFR-503: Шифрование данных

В пути (in transit):

• TLS 1.3+ для всех соединений

В покое (at rest):

• Пароли: bcrypt с salt
• Номера кредитных карт: не хранятся вообще (используется токен платёжного шлюза)
• Персональные данные: шифруются в БД (AES-256)

NFR-504: Логирование и Аудит

Логируется:

• Все попытки входа (успешные и неудачные)
• Все изменения в заказах
• Все платежи
• Все административные операции

Хранение: 1 год в защищённом журнале (защищён от модификации)

NFR-505: Соответствие нормативам

PCI-DSS: Система обработки платежей должна соответствовать PCI-DSS (Payment Card Industry Data Security Standard)

• Использование tokenization для карт
• Сертификат PCI-DSS для системы платежей

GDPR (если пользователи из ЕС):

• Возможность пользователю запросить удаление своих данных
• Privacy Policy доступна и понятна

---

6. ПРОВЕРКА ВЫПОЛНЕНИЯ ТРЕБОВАНИЙ (Testing Strategy)

6.1 Load Testing (Нагрузочное тестирование)

Инструменты: Apache JMeter, Locust, или K6

Сценарий 1: Нормальная нагрузка

1000 виртуальных пользователей
Каждый пользователь:
  1. Поиск мероприятий
  2. Просмотр доступных билетов
  3. Бронирование билета
  4. Оплата
Длительность: 10 минут

Проверяемые метрики:
- Response time P50, P95, P99
- Error rate (должен быть 0%)
- CPU, Memory на серверах

Сценарий 2: Пиковая нагрузка (открытие продаж)

50,000 одновременных пользователей
Все пытаются купить билеты на одно событие одновременно
Длительность: 5 минут

Проверяемые метрики:
- Response time не превышает максимумы
- Error rate <= 0.5%
- Ни один билет не продан дважды (консистентность)

Сценарий 3: Стресс тестирование

100,000+ одновременных пользователей
До момента, пока система не откажет
Целевой результат: > 50,000 успешных запросов в сек

6.2 Reliability Testing (Тестирование надёжности)

Chaos Engineering:

• Отключить один сервер приложения → проверить failover
• Отключить один сервер БД → проверить репликацию
• Внести случайную задержку (network jitter) → проверить retry logic
• Заполнить логи и посмотреть, как система ведёт себя

MTTR Testing:

• Вызвать критичную ошибку
• Измерить время, пока система восстановится
• Целевое значение: <= 5 минут

6.3 Performance Profiling

Инструменты: New Relic, DataDog, Jaeger для трейсинга

Процесс:

1. Запустить тест нагрузки
2. Профилировать каждый запрос (какой сервис занимает больше всего времени?)
3. Оптимизировать узкие места (например, N+1 queries в БД)
4. Повторить тест

6.4 Security Testing

Vulnerability Scanning:

• OWASP ZAP для поиска уязвимостей в веб-приложении
• Dependency scanning (Snyk) для поиска уязвимостей в библиотеках

Penetration Testing:

• Нанять external специалистов для проверки системы на уязвимости
• Минимум 1 раз в год (перед запуском)

Code Review:

• Security-focused code review перед deployment

6.5 Availability Testing

Health Check Monitoring:

Каждые 10 секунд отправляем синтетический заказ:
- Поиск мероприятия
- Проверка доступности билетов
- Если хотя бы один шаг не прошёл → алерт

Synthetic Monitoring:

• UptimeRobot для проверки доступности основного endpoint
• Проверка каждые 5 минут с разных географических локаций

---

7. ТАБЛИЦА МЕТРИК И ЦЕЛЕВЫХ ЗНАЧЕНИЙ

---

8. ПРОЦЕСС ПРИЁМКИ

• Load testing выполнен на все требования
• Performance profiling показал отсутствие узких мест
• Reliability testing пройден (MTTR < 5 мин)
• Security testing пройден (no critical vulnerabilities)
• Availability >= 99.99% в течение 2 недель на production
• Мониторинг и алерты настроены
• Документация готова (runbooks для инцидентов)
• Team обучена процедурам масштабирования