🟢 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]]