Как описывал мощность объектов?

Описание мощности (capacity) и производительности объектов в требованиях

Вопрос о том, как описывать мощность объектов, актуален при работе с системами, где нужно понимать, сколько данных может обрабатывать компонент, сколько пользователей может поддерживать система, или какой объём данных может хранить хранилище.

Терминология

1. Capacity (Ёмкость/Мощность)

Максимальный объём, который может обрабатывать или хранить система.

Примеры:

- Таблица БД может хранить 10M записей
- API может обработать 1000 запросов в секунду
- Сессия может хранить 100 активных пользователей
- Файловое хранилище может вместить 1TB данных

2. Throughput (Пропускная способность)

Количество операций, которые система выполняет в единицу времени.

Примеры:

- API: 10K requests per second (RPS)
- База данных: 1000 queries per second
- Message queue: 100K messages per minute
- CDN: 10Gbps bandwidth

3. Latency (Задержка)

Время, за которое выполняется одна операция.

Примеры:

- API response time: < 200ms (p95)
- Database query: < 50ms
- Frontend load: < 2 seconds
- Cache lookup: < 1ms

4. Scalability (Масштабируемость)

Способность системы увеличить свою мощность при росте нагрузки.

Как описать мощность в требованиях (правильно)

Шаблон для технических требований

### Performance Requirements

**Capacity:**
- Максимум пользователей одновременно: 10K
- Максимум записей в таблице X: 100M
- Максимум файлов на пользователя: 1000

**Throughput:**
- API должен обработать 1000 RPS в пиковые часы
- Background job должен обработать 10K tasks per minute
- WebSocket должен поддерживать 100K concurrent connections

**Latency (p95):**
- API response: < 200ms
- Database query: < 50ms
- Page load: < 3 seconds
- Real-time notification: < 500ms

**Availability:**
- Uptime: 99.9% (max 43 minutes downtime per month)
- Recovery time: < 5 minutes after failure

Как НЕ писать (ошибки)

❌ Размытое требование:

"Система должна быть быстрой"
"Приложение должно поддерживать много пользователей"
"База должна быть большой"

✅ Конкретное требование:

"API response time < 200ms (p95) при 1000 RPS"
"Система должна поддерживать 100K concurrent users"
"База данных должна хранить 500M записей и выполнять queries за < 50ms"

Где описывать мощность

1. Non-Functional Requirements (NFR)

Это раздел требований, где описывается производительность, безопасность, надёжность (не функциональность).

Структура документа:

## Functional Requirements
- User Story 1: пользователь может создать аккаунт
- User Story 2: пользователь может загрузить фото

## Non-Functional Requirements
### Performance
- API latency: < 200ms
- Page load: < 3 seconds

### Scalability
- Support 10K concurrent users
- Support 100M database records

### Reliability
- Uptime: 99.9%
- MTTR: < 30 minutes

2. Technical Specification (TechSpec)

Документ для инженеров, где подробно описывается, как реализовать требование.

## Scaling Strategy

### Database Sharding
- Strategy: Hash-based sharding on user_id
- Shard count: 64 shards
- Expected max records per shard: 1.5M (for total 100M)

### Caching Layer
- Technology: Redis
- TTL: 1 hour for user profile
- Expected hit rate: 80%

### Load Balancing
- Technology: NGINX round-robin
- Health check interval: 5 seconds

Примеры из реальных проектов

Пример 1: E-commerce платформа

### Non-Functional Requirements

**Traffic:**
- Peak load: 10K RPS during sale events
- Average load: 100 RPS
- Expected growth: 50% per quarter

**Data Volume:**
- Products: 10M
- Orders: 1B (growing 2M per day)
- Images: 5B

**Performance SLOs:**
- Product listing API: < 100ms (p99)
- Checkout API: < 500ms (p99) — slower is OK, user expects payment
- Search: < 200ms (p99)
- Page load (frontend): < 2 seconds

**Availability:**
- Checkout: 99.99% uptime
- Product listing: 99.9% uptime
- Search: 99% uptime (can be slow/unavailable during maintenance)

**Scalability:**
- Auto-scale API servers when CPU > 70%
- Database sharding at 80M records per shard

Пример 2: Real-time messaging app

### Non-Functional Requirements

**Concurrency:**
- 1M concurrent WebSocket connections
- 100K messages per second

**Latency:**
- Message delivery: < 100ms (p95)
- User typing indicator: < 50ms
- Read receipt: < 200ms

**Data:**
- Message history: 1 year (auto-delete after)
- Storage per user: avg 500MB (10K messages × 50KB)

**Consistency:**
- Messages delivered in order (per conversation)
- No duplicate messages
- Exactly-once delivery semantics

Пример 3: Analytics platform

### Non-Functional Requirements

**Throughput:**
- Ingest: 1M events per second
- Query: 1000 concurrent queries

**Latency:**
- Event to dashboard: < 5 minutes
- Query response: < 30 seconds (p95)

**Data:**
- Events per day: 86B
- Retention: 90 days (cold storage after)
- Total storage: 5PB

**Cost:**
- Cost per event: < $0.001
- Total monthly cost: < $86K

Как мерить и валидировать мощность

Load Testing

Прежде чем запустить в production, нужно протестировать:

1. Baseline test: какая текущая производительность?
2. Ramp-up test: как она меняется при росте нагрузки?
3. Stress test: когда система сломается?
4. Soak test: как долго система может работать под нагрузкой?

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

• JMeter (Apache)
• k6 (cloud-native)
• Locust (Python)
• Gatling (Scala)

Мониторинг в production

Метрики, которые нужно отслеживать:
- Latency (p50, p95, p99, max)
- Throughput (RPS, queries/sec)
- Error rate (% of failed requests)
- CPU / Memory / Disk usage
- Queue depth
- Cache hit rate

Правило для Business Analyst

Перед началом разработки спроси Engineering Lead:

1. Какова текущая мощность системы? (baseline)
2. Какой рост нагрузки ожидаем в следующие 6 месяцев?
3. Какие bottlenecks известны сейчас?
4. Что нужно оптимизировать в приоритете?

Ответ поможет тебе написать правильные non-functional requirements.

Вывод: мощность объектов описывается через Capacity, Throughput, Latency и Availability в разделе Non-Functional Requirements. Это критично для того, чтобы инженеры знали, к чему стремиться при разработке.