# 14. Масштабируемость

Как отличать вертикальное и горизонтальное масштабирование, где нужны partitioning, queues, read models и capacity planning.

- **Author:** Фёдор Чищин
- **Level:** advanced
- **Reading time:** ~25 минут чтения
- **Published:** 2026-05-23
- **Source:** https://fedorthinks.com/ru/learn/software-architect-14-scalability

---

## 1. Главная идея

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

### Рост бывает разным

> Ресторан может расти количеством столов, доставкой, кухнями в разных районах или скоростью обслуживания. Это разные архитектуры.

Вертикальное масштабирование увеличивает ресурсы одного узла. Горизонтальное добавляет узлы. Read replicas помогают чтению, но не записи. Sharding помогает объёму и записи, но усложняет запросы, транзакции и эксплуатацию.

Архитектор должен назвать axis of scale. Система, хорошо масштабируемая по чтению, может плохо масштабироваться по записи. Сервис, выдерживающий нагрузку, может не масштабироваться организационно, если все изменения требуют одной команды.

### Capacity planning лучше героизма

> Проще заранее знать вместимость зала, чем открывать двери и надеяться, что стены раздвинутся.

Capacity planning отвечает на вопросы: сколько нагрузки есть сейчас, какой рост ожидается, где предел, какой lead time на расширение, какие alarms покажут приближение к лимиту.

Без этого команда узнаёт о лимитах от пользователей. Это всегда дороже.

## 2. Пример и антипример

Масштабируемость должна расти от реального профиля нагрузки, а не от абстрактного страха будущего.

### Пример: 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?
- Какой сигнал покажет, что пора менять архитектуру?
- Можно ли отложить сложность, сохранив путь миграции?

Следующий модуль: [Надёжность](./software-architect-15-reliability).