API

Продуктивність і надійність

Види навантажувальних тестів і перцентилі

Тип	Що робимо	Що шукаємо
Load	Очікуване робоче навантаження тривалий час	Чи тримаємо SLA за нормальних умов
Stress	Поступово підіймаємо навантаження вище норми	Точку відмови і як система деградує
Spike	Різкий стрибок, наприклад у 10 разів за хвилину	Чи витримує сплеск і чи відновлюється
Soak	Помірне навантаження багато годин	Витоки пам'яті, переповнення пулів з'єднань

Інструменти — k6, JMeter, Gatling, Locust.

Чому не середнє. Середній час 200 ms може ховати те, що кожен двадцятий запит триває 5 секунд. Тому дивляться перцентилі: p95 — 95% запитів швидші за це значення, p99 — 99%. SLA зазвичай формулюють так: «p95 < 500 ms при 200 RPS, помилок менше 0.1%». Хвіст p99 часто болить найбільше, бо одна сторінка робить десятки запитів, і хтось майже завжди потрапляє в повільний.

Важливо тестувати на середовищі, близькому до продакшну, з реалістичними даними: на порожній базі все швидко.

На співбесіді: Load перевіряє очікуване навантаження, stress шукає межу, spike — різкий сплеск, soak — стабільність за довгий час. Я оцінюю p95 і p99, а не середнє, бо середнє ховає повільний хвіст.

Таймаути, ретраї та idempotency keys

Таймаути. Кожен виклик до іншого сервісу має мати таймаут, інакше один завислий сервіс тримає потоки й з'єднання, і падає все. Тестую, що при повільній залежності клієнт отримує контрольовану помилку (часто 504 від шлюзу) за прогнозований час, а не висить хвилину.

Ретраї з backoff. Повторювати можна лише тимчасові помилки: таймаут, 429, 502, 503, 504. На 400 чи 422 ретрай безглуздий — результат не зміниться. Повтори роблять з exponential backoff (1 s, 2 s, 4 s) і jitter — випадковим зсувом, щоб тисячі клієнтів не вдарили сервер одночасно. Кількість спроб обмежена.

Idempotency keys. Ретрай неідемпотентного POST небезпечний: таймаут не означає, що запит не виконався, можливо, загубилась лише відповідь. Тому клієнт генерує Idempotency-Key один раз на операцію і передає його в усіх повторах, а сервер віддає збережений результат замість другого платежу.

Тест-кейс для фінтеху: емулювати таймаут відповіді (наприклад, через проксі чи мок залежності), дочекатися ретраю клієнта і перевірити в базі, що переказ один.

На співбесіді: Я перевіряю, що виклики мають таймаути, а ретраї відбуваються лише на тимчасових помилках з exponential backoff і jitter. Для платежів кожен ретрай іде з тим самим Idempotency-Key, і я перевіряю, що в базі одна транзакція.

429, 503, Retry-After і circuit breaker

429 Too Many Requests — клієнт перевищив ліміт. 503 Service Unavailable — сервіс тимчасово не може обробити запит: перевантаження, деплой, залежність лежить. Обидва можуть мати заголовок Retry-After — кількість секунд або дата, після якої варто повторити:

HTTP/1.1 429 Too Many Requests
Retry-After: 30

Коректний клієнт поважає Retry-After і не ретраїть раніше. Що перевіряю: ліміт спрацьовує на правильному порозі; заголовок присутній і має валідне значення; після паузи запити знову проходять; клієнт (наш фронтенд чи сервіс) показує зрозуміле повідомлення, а не крутить спінер вічно.

Circuit breaker — запобіжник між сервісами. Якщо залежність падає раз за разом, breaker «розмикається» (стан open), і виклики до неї одразу повертають помилку чи fallback, не чекаючи таймауту. Через деякий час він пропускає кілька пробних запитів (half-open): якщо вони успішні — замикається назад (closed). Це не дає падінню одного сервісу каскадом покласти всю систему.

Для QA це сценарії відмовостійкості: вимкнути чи сповільнити залежність і перевірити, що основний сервіс відповідає швидко з контрольованою помилкою або fallback, а після відновлення залежності все повертається в норму без ручного втручання.

На співбесіді: На 429 і 503 я перевіряю наявність Retry-After і те, що клієнт його поважає. Circuit breaker при серії відмов перестає ходити в залежність і швидко повертає помилку чи fallback, і я тестую це, вимикаючи залежність і перевіряючи відновлення.