ЗмістНатисність на посилання, щоб перейти до потрібного місця
Thundering herd problem - це ситуація в розробці ПЗ, коли багато процесів або запитів одночасно звертаються до одного й того самого ресурсу. Кожен із них діє логічно та правильно, але разом вони створюють різкий сплеск навантаження, який система не витримує.
Назва метафорична: уявіть стадо тварин, яке одночасно зірвалося з місця. Окремо кожна тварина не є проблемою, але разом вони здатні знести все на своєму шляху.
Приклад Thundering Herd
На практиці це часто виглядає так: у вас є кеш з TTL. Ключ згорає, і в той самий момент приходить багато запитів. Кожен із них бачить, що кеш порожній, і вирішує самостійно сходити в базу даних або зовнішній сервіс. У результаті замість одного контрольованого запиту ви отримуєте сотні або тисячі. База перевантажується, latency росте, з’являються таймаути, а інколи й повне падіння сервісу. Кеш, який мав захищати систему, фактично перетворюється на тригер аварії.
Ця проблема особливо підступна тим, що виникає не в спокійних умовах, а саме в найгірші моменти: під час пікового трафіку, після рестарту сервісів, на деплої або коли зовнішня залежність починає відповідати повільніше. Локально або на стейджингу її майже неможливо відтворити, тому в продакшені вона виглядає як "рандомний" інцидент без очевидної причини.
Як боротися з thundering herd?
Боротися з thundering herd можна по-різному, але ідея завжди одна: система не повинна поводитися надто синхронно. Часто достатньо дозволити лише одному процесу оновлювати кеш, поки всі інші або чекають, або читають попереднє значення. В інших випадках краще тимчасово віддати трохи застарілі дані, ніж створити лавину запитів до бази. Навіть дрібна деталь на кшталт випадкового зсуву TTL може значно зменшити ризик, що всі ключі протухнуть одночасно.
Окрема категорія проблем - це ретраї. Коли сервіс падає або відповідає повільно, наївна retry-логіка змушує клієнтів повторювати запити синхронно. Замість відновлення система отримує ще більший удар. Тому затримки, exponential backoff і випадковий джитер - не оптимізація, а необхідність.
Thundering herd - це не баг у коді, а наслідок архітектурних рішень. Він з’являється там, де система масштабується кількісно, але не враховує конкуренцію за спільні ресурси. Якщо думати не лише про "як працює", а й про "як поводиться під навантаженням", цієї проблеми можна уникнути ще на етапі дизайну.
Цей допис поки що не має жодних доповнень від автора/ки.
