Каскадна відмова - збій одного компонента поширюється на інші й валить усю систему. Типовий сценарій:
- сервіс рекомендацій сповільнився (відповідає за 30 секунд замість 50 мс);
- процеси PHP, що чекають на нього, не звільняються;
- пул процесів вичерпано - уся сторінка товару, а за нею й увесь сайт перестає відповідати;
- користувачі оновлюють сторінку - навантаження зростає, повторні спроби добивають систему.
Причина - не відмова рекомендацій, а те, що від них синхронно залежала критична частина.
Плавна деградація - при збої некритичної частини система продовжує виконувати головне, з урізаною функціональністю:
- рекомендації недоступні - сторінка товару без блоку рекомендацій;
- пошук перевантажений - простий пошук за назвою замість повнотекстового;
- платіжний провайдер не відповідає - замовлення приймається зі статусом «очікує оплати».
Механізми:
1. Тайм-аути на всі зовнішні виклики - короткі, розраховані на нормальну відповідь, а не на «стандартні 30 секунд»:
Http::timeout(2)->connectTimeout(1)->get($url);
2. Запобіжник (circuit breaker) - після серії помилок перестати викликати сервіс на якийсь час і одразу повертати запасний варіант. Сервіс отримує час відновитися, а запити - швидку відповідь замість очікування.
3. Запасні відповіді (fallback) - кешоване значення, порожній блок, спрощена версія.
4. Ізоляція ресурсів (bulkheads) - окремі пули процесів, черги й з'єднання для різних залежностей: проблеми з однією не займають ресурси інших.
5. Обмеження й скидання навантаження (load shedding) - при перевантаженні відмовляти частині запитів одразу (503), щоб решта обслуговувалася нормально, - замість того щоб повільно обслуговувати всіх.
6. Повтори з експоненційною затримкою й розкидом - і з обмеженою кількістю; бездумні повтори множать навантаження на сервіс, що й так не справляється.
7. Асинхронність - некритичне (аналітика, листи, синхронізації) у черги, щоб збій отримувача не впливав на відповідь користувачу.
8. Прапорці функцій - швидко вимкнути важку функцію під час інциденту без деплою.
Перевірка: навмисно «вимикати» залежності в тестовому середовищі (chaos testing) і дивитися, що відбувається з головними сценаріями.
Докладніше в документації: Google SRE Book: каскадні відмови