7 мая 2026 г.·3 мин чтения

Capacity planning на собеседовании системного аналитика

Готовься к собесу аналитика как в Duolingo
10 минут в день — SQL, Python, A/B, метрики. 1700+ вопросов в Telegram
Открыть Карьерник в Telegram

Карьерник — Duolingo для аналитиков: 10 минут в день тренируй SQL, Python, A/B, статистику, метрики и ещё 3 темы собеса. 1500+ вопросов в Telegram-боте. Бесплатно.

Содержание:

Зачем спрашивают на собесе SA

Capacity planning — часть system design. На собесе SA: «как планировать», «peak load», «headroom».

Estimation

Bottom-up. Из bus-метрик в technical numbers.

1M DAU × 50 actions / day / user = 50M events / day
50M / 86400 sec ≈ 580 events / sec average

Peak (10× average) = 5800 events / sec

Storage.

Event size = 1 KB.
50M / day × 1 KB = 50 GB / day.
50 GB × 365 = 18 TB / year.

С compression / parquet — 10× меньше storage.

Peak vs average

Системы не получают uniform traffic.

Daily pattern. Peak hours (рабочее время в местном time zone). Ночью drop 5-10×.

Weekly. Weekday vs weekend.

Seasonal. Black Friday, Christmas — 5-10× spikes.

Marketing campaigns. Известные spikes.

Capacity для peak, не average. Иначе outage.

Headroom

Buffer above peak.

Capacity = peak × (1 + headroom)

Standard headroom — 30-50%.

Зачем:

  • Unexpected spike.
  • Failed instance — survivors take more load.
  • Scaling latency — auto-scale takes time.
Готовься к собесу аналитика как в Duolingo
10 минут в день — SQL, Python, A/B, метрики. 1700+ вопросов в Telegram
Открыть Карьерник в Telegram

Bottlenecks

Где упрётся раньше всего.

Compute. CPU / memory limits.

Database. Connections, write throughput, query performance.

Network. Bandwidth, especially для cross-region.

External services. API rate limits, third-party SLAs.

Disk I/O. Часто забывают, но критично для DBs.

Lock contention. Не infrastructure но scaling-blocker.

Идентификация bottleneck — load testing.

Autoscaling

Auto add / remove instances based на metrics.

Triggers:

  • CPU utilization (например, scale up at 70%).
  • Memory.
  • Queue depth.
  • Custom metrics (RPS, response time).

Tools: k8s HPA, AWS Auto Scaling, Cloud Run autoscale.

Caveats:

  • Scale up takes time (provisioning, warmup).
  • Cold start latency.
  • DB не scales linearly с stateless services.

Cost trade-offs

Over-provisioning. Always 100% capacity → expensive.

Under-provisioning. Cheap, but outages.

Reserved capacity. AWS Reserved Instances / Savings Plans — 30-70% cheaper, но commitment.

Spot / preemptible. Cheap (50-90% off), но могут shutdown в любой момент. Подходит для batch / fault-tolerant.

Multi-tier. Hot path — premium tier. Cold path — cheap tier (Glacier, batch processing).

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

FAQ

Capacity planning для startups?

Estimate более roughly. Часто over-provision (cheap), focus на product fit. Optimize позже.

Это официальная информация?

Нет. Статья основана на стандартных подходах SRE / capacity engineering.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.

Ещё по теме