Когда система перестаёт держать нагрузку, приходит время масштабироваться
Обычно делают так:
- добавили инстансы → стало не лучше
- распилили на микросервисы → стало хуже
Scale Cube модель предлагает 3 оси. Каждая закрывает свой bottleneck:
X - клонирование
Больше одинаковых копий сервиса за балансером.
Помогает, когда упираетесь в CPU/IO на приложении.
Y - разделение ответственности
Делите по функциям: поиск, отчёты, платежи.
Нужно, когда одна часть системы “убивает” остальных и её надо изолировать/масштабировать отдельно.
Z - разделение по данным (sharding/partitioning)
Делите данные по ключу (
user_id, region).Применяется когда потолок - данные: одна БД/таблица, hot keys, локи. Запись и чтение можно масштабировать отдельно
Например, если узкое место - база, то:
- X почти не поможет (вы просто сильнее нагрузите БД)
- микросервисы чаще ухудшат (больше запросов + распределённые транзакции/консистентность)
- а вот Z может дать рост capacity
Выбирать ось надо по bottleneck’у.
Если вы не можете назвать узкое место цифрами - вы не масштабируете, а только усложняете систему.
🚀 Пост Guru PHP: @msavin_dev