back-of-envelope.js·4 scenarios
Back-of-envelope estimation: одна e-commerce-архитектура (CDN, LB, API, Redis cache, Postgres primary + read-replica), 4 сценария роста — 1K / 100K / 10M / 300M DAU. Каждый сценарий показывает где появляется bottleneck и какое решение его снимает. Демонстрирует каркас оценки в 5 шагов: DAU × ops × peak factor → RPS, payload × ops × users × retention → storage, read/write ratio → cache+replica/sharding decisions.
На любом интервью, дизайн-сессии или внутреннем review первое, что нужно сделать после уточнения требований — посчитать порядок чисел. RPS, объём данных, bandwidth, hot/cold-разделение. Без этого все архитектурные решения — карго-культ: «давайте Kafka, потому что Netflix», «возьмём шардинг, потому что у Uber есть».
Back-of-envelope даёт три вещи, ради которых стоит потратить пять минут:
Цель оценки — не точность, а порядок (правильный «логарифм»). Ошибка в 2-3 раза — норма. Ошибка в 100 раз — катастрофа.
«Назови мне DAU и средний размер payload — я скажу тебе, нужен ли тебе шард, кеш и CDN.»
Каркас в 5 шагов (Alex Xu, System Design Primer):
Sanity-чек numbers (держи в голове, ниже подробно):
На канвасе — типовой e-commerce-стек одного региона: CDN → Load Balancer → API → Redis → Postgres (primary + read-replica). Те же шесть компонентов мы будем «гонять» через четыре масштаба нагрузки и смотреть, где какая нода становится узким местом.
API-нода несёт decisions: [ADR-001] — раскрывается на канвасе в полное объяснение методики, источники и sanity-numbers.
Диаграмма намеренно не меняется между сценариями: меняется только режим нагрузки, а ноды подсвечиваются жёлтым/красным glow, когда расчётный RPS превышает их capacity. Это и есть суть back-of-envelope — одна и та же архитектура либо тривиальна, либо разваливается в зависимости от того, какие числа ты в неё подставил.
small-1k — 1K DAU, single server хватаетВход: 1K DAU, 10 ops/user, 5KB payload, peak factor x3.
Расчёт: 1K × 10 = 10K ops/day = 0.12 RPS avg, peak ≈ 0.35 RPS. Storage: 10K × 5KB = 50MB/day → 18GB/year.
Вывод: один dyno + один small Postgres. CDN, cache, replica — overkill. Стоимость: ~$20/мес. На канвасе все ноды зелёные.
Это типичный MVP. 90% стартапов живут здесь годами и тратят деньги на инфру, которая им не нужна.
medium-100k — 100K DAU, нужен cache + read-replicaВход: 100K DAU, 10 ops/user, 5KB, read/write = 100
.Расчёт: 1M ops/day ≈ 12 RPS avg, peak ≈ 35 RPS. Разбивка: ~34.6 read RPS, 0.34 write RPS.
Узкое место: reads растут линейно с DAU. Single DB ещё справится, но запас тает. Storage: 5GB/day → 1.8TB/year — уже managed Postgres, не laptop.
Решение: добавить Redis перед DB. При 80% hit rate — всего 7 reads/s до DB. Read-replica для cache miss. Primary — только writes. Бюджет: ~$200/мес, headroom ×10.
large-10m — 10M DAU, CDN + sharding + горизонтальное масштабированиеВход: 10M DAU, 10 ops, 5KB, read/write = 100
.Расчёт: 100M ops/day ≈ 1160 RPS avg, peak ≈ 3500 RPS. Storage: 500GB/day = 180TB/year — один диск не вытянет.
Узкие места:
Решения: CDN на edge (картинки/JS/CSS, $0.01/GB), Redis Cluster (3 shards, 300K RPS суммарно), sharding Postgres по user_id (4 шарда × 25TB), 5 API-нод (3500 / 5K = ~1 нужен, 5 для HA/AZ). Bandwidth: 17 MB/s = 140 Mbps egress — норм для одного DC. Бюджет: ~$5K/мес.
twitter-300m — fanout problem, single-DB ломается полностьюВход: 300M DAU, 5 ops/user, 1KB payload, средне 200 followers/user.
Расчёт: 1.5B ops/day ≈ 17.4K RPS avg, peak ≈ 87K RPS. Writes: 600M tweets/day = 7K writes/s. Reads: ~700K/s. Fanout: каждый tweet × 200 followers = 1.4 миллиарда timeline writes/day.
Узкие места: 16K timeline writes/s в один DB — невозможно. Storage: 600M × 1KB tweets + 1.4B × 8B timeline references = 11TB/day = 4PB/year. Bandwidth: 87 MB/s × N DC = multi-region egress = $$$.
Решения: pre-computed timelines в Redis (push model для 90% обычных юзеров), pull model для celebrity (Bieber, 100M followers — fanout-on-read), 1000 шардов × 4TB, multi-region. Бюджет: $10M+/мес.
Главный урок сценария: back-of-envelope за 30 секунд показал, что это не CRUD-задача с одним Postgres. До первой строки кода.
ADR-001: оценивай ДО того, как кодишь.
Контекст. На любой дизайн-сессии или интервью первое, что нужно — посчитать порядок чисел. Без back-of-envelope все решения о шардинге, кешировании, CDN — карго-культ. Точность не нужна, нужен правильный логарифм: 1K RPS и 1M RPS требуют принципиально разной архитектуры.
Решение. Каркас в 5 шагов: Users → Ops/user → Payload → Storage → Read/Write ratio. Sanity-чек по таблице known-numbers: 1 API ~5K RPS, Postgres ~10–30K RPS, Redis ~100K RPS, Kafka ~50K msg/s, 1 Gbps ≈ 125 MB/s.
Trade-offs:
| За | Против |
|---|---|
| Раннее обнаружение масштаба | Может звучать как «гадание на кофе» без практики |
| Защита от over-engineering и premature optimization | Числа стареют (CPU, диск, сеть дешевеют) — обновляй таблицу раз в год |
| Общий язык на интервью | Не заменяет нагрузочное тестирование на проде |
| Один из самых дешёвых способов снять риск | Не учитывает «long-tail» (P99 latency, geo-распределение, GC паузы) |
Когда trade-off перевешивает в сторону «не считать»: только когда ты явно спекулятивно прототипируешь идею за час, и тебя не волнует стоимость через 6 месяцев. В остальных 99% случаев — считай.
Считают peak = average. Реальный peak в 3–10 раз выше среднего. Утренние пики, релизы, новости. Если ты планируешь на average — упадёшь в первый же spike.
Забывают про метаданные. ID, timestamp, user_id, индексы, версионирование — payload растёт в 2–3 раза от голого тела сообщения. Tweet — это не 280 байт, это ~1KB после всех метаданных.
Считают только storage, забывают про bandwidth. Egress = деньги, особенно cross-region. 100 Mbps × 24/7 = 32 TB/мес × $0.09/GB ≈ $2900/мес. Это часто крупнее всех остальных расходов.
Не различают hot/cold storage. Cold (S3 IA, Glacier) в 10 раз дешевле SSD. Если 95% данных читается раз в год — нет смысла держать их на NVMe. Retention policy = деньги.
Округление в неправильную сторону. «Один сервер тянет 10K RPS» — это в идеале с прогретым кешем и без выбросов. Закладывай 30–50% headroom, иначе любой incident выбьет SLA.
Игнорируют read-amplification. Один запрос пользователя = N запросов в БД (joins, fanout, cache miss waterfall). Считай RPS на БД, не только на API.