Как система выдерживает 3000 пользователей… и всё равно ломается
Представим проект сервиса оформления заказов.
Архитектура выглядит так:
Frontend
↓
API Gateway
↓
Order Service
↓
Kafka
↓
Payment Service
↓
PostgreSQL
По требованиям система должна выдерживать:
3000 одновременных пользователей в пиковые часы распродаж.
🧪Подготовка нагрузочного теста
Сценарий максимально близкий к реальности.
Типичный пользователь:
1️⃣ открывает каталог
2️⃣ добавляет товар в корзину
3️⃣ оформляет заказ
4️⃣ оплачивает
Think time между действиями: 3–5 секунд
Инструмент: k6
Профиль нагрузки:
0 → 500 пользователей (2 минуты)
500 → 2000 пользователей (5 минут)
2000 → 3000 пользователей (5 минут)
Метрики:
p95 latency
error rate
throughput
CPU
Kafka lag
DB connections
📊 Первые результаты
До 2000 пользователей всё выглядело идеально.
Метрики:
p95 latency: 180ms
errors: 0%
CPU: 40%
Команда была уверена: “Система выдержит 3000 легко.”
Но дальше началось интересное.
🚨 На 2500 пользователей началась деградация
Система не падала, но метрики начали ползти.
p95 latency: 400ms
Kafka lag: растёт
DB connections: растут
При этом:
- ошибок почти нет
- CPU не перегружен
- Система формально работает.
Но что-то явно идёт не так.
🔎 Начали копать глубже
Посмотрели метрики Kafka.
И увидели:
producer rate: 1500 msg/sec
consumer rate: 1200 msg/sec
Каждую секунду система накапливала 300 сообщений.
Это значит:
lag растёт
очередь растёт
задержки растут
Но API продолжает отвечать 200 OK.
🧨 Через 15 минут начинается лавина
Kafka lag:
0 - 10k - 40k - 120k сообщений
Теперь происходит следующее:
1️⃣ Payment Service начинает отставать
2️⃣ пользователи ждут подтверждение оплаты
3️⃣ система делает retry
4️⃣ нагрузка увеличивается ещё сильнее
Начинается feedback loop.
💥 Итог через 20 минут теста
Метрики:
p95 latency: 6 секунд
error rate: 12%
Kafka lag: 200k сообщений
Но что интересно - система не упала. Она просто стала очень медленной.
🧠 Где была реальная проблема
После расследования оказалось:
Payment Service был bottleneck.
Он обрабатывал: 1200 сообщений/сек
А система генерировала:
1500 сообщений/сек.
Разница:
+300 сообщений/сек
Это маленькое расхождение и убивало систему.
🛠 Как исправили
Решения:
1️⃣ Увеличили количество consumer
Kafka consumers:
3 → 6
2️⃣ Добавили batching платежей
Вместо:
1 message → 1 DB transaction
Сделали:
10 messages → 1 transaction
3️⃣ Ограничили retries
Retry storm сильно усиливал нагрузку.
📊 Результат после фикса
Повторили тест.
Метрики:
3000 пользователей
p95 latency: 320ms
Kafka lag: стабилен
errors: 0.2%
Система выдержала нагрузку.
🎯 Самый важный вывод
Без нагрузочного теста этот баг проявился бы:
только на распродаже
только под реальной нагрузкой
только через 15–20 минут
То есть: в продакшене ⚡️
💡 Главный урок для QA
Нагрузка показывает не только выдержит ли система
Она показывает:
как система деградирует со временем
И самые опасные проблемы - это те, которые:
- не падают сразу
- не дают ошибок
- но медленно убивают систему.
📓 Заметки тестировщика