🟢 Junior Level

Горизонтальное масштабирование — это добавление большего количества инстансов сервиса для обработки нагрузки.

Вертикальное масштабирование (больше CPU/RAM) упирается в предел одного сервера и требует даунтайма. Горизонтальное теоретически бесконечно и без даунтайма.

Один инстанс:
Client → Service

Горизонтальное масштабирование:
Client → Load Balancer → Service #1
                       → Service #2
                       → Service #3

Способы:

1. Kubernetes — автоматически (HPA — Horizontal Pod Autoscaler, K8s автоматически добавляет Pod’ы при росте нагрузки)
2. Docker Compose — docker-compose up --scale service=3
3. Cloud — auto-scaling группы

---

🟡 Middle Level

Когда НЕ использовать горизонтальное масштабирование

• Stateful сервисы (WebSocket-соединения, in-memory кэши)
• Лицензионное ПО с per-instance стоимостью
• Сервисы с дорогой инициализацией (минуты на запуск)

Kubernetes HPA

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: user-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: user-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
// 70% — запас для пиков нагрузки. При 90% новый инстанс не успеет запуститься
// до скачка. При 50% будете переплачивать за лишние инстансы.

Statelessness

Для горизонтального масштабирования сервисы должны быть stateless:
(Stateless — сервис не хранит состояние в памяти; любой инстанс взаимозаменяем.)
✅ Нет локального состояния
✅ Сессия в Redis
✅ Данные в БД
✅ Конфигурация извне

Типичные ошибки

1. Stateful сервисы:

   Сессия в памяти → при масштабировании запросы идут на другой инстанс → нет сессии
   Решение: внешнее хранилище сессий
   

---

🔴 Senior Level

Custom metrics

metrics:
- type: Pods
  pods:
    metric:
      name: http_requests_per_second
    target:
      type: AverageValue
      averageValue: 1000

Production Experience

Blue-Green Deployment:

(Blue-Green Deployment — стратегия деплоя без даунтайма: два окружения, переключение трафика.)
v1 (Blue) → production traffic
v2 (Green) → развёрнут, тестируется
Переключить трафик на v2 → откатить если проблемы

Best Practices

✅ Stateless сервисы
✅ Health checks
✅ Graceful shutdown
✅ Resource limits
✅ Monitoring + alerting

❌ Stateful без внешнего хранилища
❌ Без resource limits
❌ Без graceful shutdown

---

🎯 Шпаргалка для интервью

Обязательно знать:

• Горизонтальное масштабирование = больше инстансов за load balancer
• Вертикальное = больше CPU/RAM, упирается в предел одного сервера
• Сервисы MUST быть stateless для горизонтального масштабирования
• Kubernetes HPA — автоматическое масштабирование по CPU/metrics (70% CPU target)
• Сессия в Redis, данные в БД, конфигурация извне
• Blue-Green deployment — деплой без downtime
• НЕ подходит для stateful сервисов (WebSocket, in-memory кэш)

Частые уточняющие вопросы:

• Почему 70% CPU target? Запас для пиков нагрузки — при 90% новый инстанс не успеет запуститься.
• Как сделать сервис stateless? Сессия в Redis, данные в БД, конфигурация извне, нет локального состояния.
• Что такое graceful shutdown? Завершение текущих запросов перед остановкой, deregister из Registry.
• Custom metrics для HPA? http_requests_per_second, queue length, business metrics.

Красные флаги (НЕ говорить):

• “Stateful сервисы легко масштабировать” — нет, нужно external state management
• “Вертикальное масштабирование всегда проще” — да, но упирается в предел
• “HPA с 90% CPU — эффективно” — нет, не успеет масштабироваться при пике
• “Сессия в памяти — нормально” — нет, запросы пойдут на другой инстанс

Связанные темы:

• [[10. Что такое шардирование sharding]]
• [[11. В чём разница между шардированием и партиционированием]]
• [[26. Какие инструменты используются для оркестрации микросервисов]]
• [[7. Что такое Service Discovery и зачем он нужен]]
• [[13. Что такое паттерн Database per Service]]