Закон протекающих абстракций и почему он портит вам tail latency

Закон протекающих абстракций говорит о том, что любая удобная обёртка рано или поздно перестаёт скрывать свою сложность.

Tail latency — это когда запрос, обычно делающийся за 200 ms, внезапно занимает 2 s. Такое поведение ухудшает пользовательский опыт - пользователь может не дождаться и уйти. В распределённой системе эффект еще и усиливается: один затупивший вызов тянет за собой всю цепочку

Почему появляются такие задержки? Сеть потеряла пакет, TCP ушёл в backoff, DNS задумался, GC начал собирать мусор не вовремя, прокси сделал лишний ретрай. В обычном коде всё выглядит гладко, но под нагрузкой эти мелочи превращаются в p95/p99 latency

Как бороться с tail latency? Есть ряд паттернов:
- хеджированные запросы - отправляем запрос на несколько нод сразу, и берем ответ от первого
- request coalescing - одинаковый запросы "склеиваем" в один, чтоб не грузить нижние слои системы
- deadline propagation - каждый участок запроса знает сколько у него осталось времени на выполнение
- circuit breakers - если модуль стал отдавать много ошибок, можно отрезать часть запросов от него, чтоб дать ему восстановиться
- latency-aware load balancing - раскидывать нагрузку не round-robin'ом, а в зависимости от состояния нод

Каждый паттерн — отдельная история, но вместе они сильно уменьшают хвосты.

🚀 Пост Guru PHP: @msavin_dev

Blue-Green Deployment

Blue-green — это способ выкатывать новую версию без простоя и практически с мгновенным откатом на старую версию если что-то пошло не так

У вас есть два окружения — blue (текущий прод) и green (новая версия).
Вы обновляете green, прогоняете smoke-тесты, а потом просто переключаете трафик на него.
Переключение обычно занимает миллисекунды — достаточно указать load balancer’у новый бэкенд.
При этом мы имеем такую же простую возможность отката, если что-то все таки пошло не так - переключаем трафик на blue и спокойно правим green

Но есть важный нюанс - база данных и любые другие контракты данных должны быть совместимы между соседними версиями.
Обе версии (blue и green) должны уметь работать с одной и той же схемой БД одновременно. То же самое касается схемы кеша, форматов сообщений, протоколов очередей — разве что здесь можно выкрутиться версионированием ключей.

Blue-green не решает все проблемы, но снимает главный страх релизов:
“если что-то поломается, мы вернём всё назад за секунду”.

🚀 Пост Guru PHP: @msavin_dev

Scale Cube: 3 способа масштабироваться

Когда система перестаёт держать нагрузку, приходит время масштабироваться
Обычно делают так:

- добавили инстансы → стало не лучше
- распилили на микросервисы → стало хуже

Scale Cube модель предлагает 3 оси. Каждая закрывает свой bottleneck:

X - клонирование
Больше одинаковых копий сервиса за балансером.
Помогает, когда упираетесь в CPU/IO на приложении.

Y - разделение ответственности
Делите по функциям: поиск, отчёты, платежи.
Нужно, когда одна часть системы “убивает” остальных и её надо изолировать/масштабировать отдельно.

Z - разделение по данным (sharding/partitioning)
Делите данные по ключу (user_id, region).
Применяется когда потолок - данные: одна БД/таблица, hot keys, локи. Запись и чтение можно масштабировать отдельно

Например, если узкое место - база, то:

- X почти не поможет (вы просто сильнее нагрузите БД)
- микросервисы чаще ухудшат (больше запросов + распределённые транзакции/консистентность)
- а вот Z может дать рост capacity

Выбирать ось надо по bottleneck’у.
Если вы не можете назвать узкое место цифрами - вы не масштабируете, а только усложняете систему.

🚀 Пост Guru PHP: @msavin_dev