Горизонтальное масштабирование

Горизонтальное масштабирование добавляет инстансы сервиса вместо более мощной машины. Лучше работает при **stateless** app tier: сессии в Redis, загрузки в object storage, sticky sessions только если неизбежны.

					Traffic → LB → [App₁, App₂, App₃] → Shared DB / Cache / Queue
				

| Требование | Зачем | |------------|-------| | Stateless handlers | Любой инстанс может обслужить запрос | | Shared durable state | БД, cache, object storage — не локальный диск | | Health checks | LB убирает плохие инстансы | | Autoscaling signals | CPU, RPS, queue depth, custom SLI |

Планируйте **rolling deploys** и математику connections: больше инстансов — больше pool connections к БД без pooler.

На интервью: stateless vs sticky sessions; когда проще vertical scale; lag autoscaling при скачках; trade-off data locality.

Типовые ошибки: in-memory sessions на нескольких pod; локальные file uploads; scaling до исправления синхронного DB bottleneck.

Компромисс — эластичная ёмкость против сложности распределённой системы и стоимости N машин.

Чеклист:

• Сессии и uploads снаружи инстанса.
• Autoscale по пользовательским сигналам где возможно.
• Deploy с новыми инстансами mid-traffic.
• Лимиты connections на инстанс.