Software Architect · Модуль 14
Scalability — это способность системы расти по нужной оси без непропорционального роста сложности и стоимости.
Vertical scaling · horizontal scaling · partitioning · capacity
Масштабировать нужно конкретную нагрузку: пользователей, записи, чтения, объём данных, команды или регионы.
Рост бывает разным
Ресторан может расти количеством столов, доставкой, кухнями в разных районах или скоростью обслуживания. Это разные архитектуры.
Вертикальное масштабирование увеличивает ресурсы одного узла. Горизонтальное добавляет узлы. Read replicas помогают чтению, но не записи. Sharding помогает объёму и записи, но усложняет запросы, транзакции и эксплуатацию.
Архитектор должен назвать axis of scale. Система, хорошо масштабируемая по чтению, может плохо масштабироваться по записи. Сервис, выдерживающий нагрузку, может не масштабироваться организационно, если все изменения требуют одной команды.
Capacity planning лучше героизма
Проще заранее знать вместимость зала, чем открывать двери и надеяться, что стены раздвинутся.
Capacity planning отвечает на вопросы: сколько нагрузки есть сейчас, какой рост ожидается, где предел, какой lead time на расширение, какие alarms покажут приближение к лимиту.
Без этого команда узнаёт о лимитах от пользователей. Это всегда дороже.
Масштабируемость должна расти от реального профиля нагрузки, а не от абстрактного страха будущего.
Пример: read-heavy продукт
В библиотеке книги читают тысячи людей, но редактирует каталог небольшая команда.
Документационный сервис имеет много чтений и мало записей. Архитектура использует CDN, static generation, edge caching и read-optimized search index. Source of truth остаётся простой.
Это хороший trade-off: чтение масштабируется дешево, запись остаётся управляемой.
Антипример: sharding до первых клиентов
Строить развязку на восемь полос к гаражу, где стоит одна машина, дорого и неудобно.
Команда сразу проектирует sharded database, routing layer и distributed transactions, хотя продукт ещё ищет market fit. Разработка замедляется, миграции усложняются, а реальная нагрузка неизвестна.
Scalability должна оставлять путь роста, но не обязана заранее реализовывать каждый будущий уровень.
- По какой оси система должна расти первой? - Где текущий capacity limit? - Какой сигнал покажет, что пора менять архитектуру? - Можно ли отложить сложность, сохранив путь миграции?