Оценка на салфетке (back-of-the-envelope)
Прежде чем выбрать дизайн — оцени его: QPS, объём за 5 лет, пропускную способность сети, размер кэша. Расчёт за две минуты с округлением до одной значащей цифры дёшево отсекает неверную архитектуру и показывает, какой ресурс сломается первым.
Двое инженеров час спорят, кэшировать ли ленту в памяти или читать с диска на каждый запрос. Третий хватает салфетку: 100М пользователей, каждый открывает приложение 5 раз в день, — это ~6 000 чтений/с в среднем и, может, 30 000 на пике; горячий набор ленты ~50 ГБ, что влезает в RAM на паре машин. Спор окончен за полторы минуты — не потому, что салфетка точна, а потому, что она верна с точностью до порядка, а больше решению и не требовалось. Джефф Дин построил значительную часть инфраструктуры Google ровно на этой привычке: оценивай дизайн до того, как его строить.
Зачем оценивать до сборки
За десять минут у тебя будет метод, который позволяет убивать плохие архитектуры до того, как кто-то напишет строчку кода — и точно знать, какой ресурс сломается первым.
Оценка на салфетке — это быстрая прикидка из нескольких известных чисел и рассуждений на уровне порядков, которой решают, какой дизайн правдоподобен, до написания кода или закупки железа. Смысл не в точности — в отсеве. Если прикидка говорит, что один инстанс Postgres должен впитывать 400 000 записей/с, бенчмарк не нужен — одноузловой дизайн мёртв; ты отверг его по цене салфетки.
Junior-инстинкт — пропустить это и «просто собрать, потом измерить». Работает до момента, когда собранное заняло три недели, а измерение говорит, что форма была неверной с самого начала. Senior-инстинкт — потратить две минуты на вопрос: какова нагрузка, во что она обходится по каждому ресурсу и какой ресурс упрётся в потолок первым? Оценивают четыре величины — QPS (темп запросов), объём (байты в покое, спроецированные на годы), трафик (байты в движении в секунду) и память (рабочий набор, что хочешь держать горячим в кэше) — потому что именно они и заканчиваются.
Две таблицы чисел, что держишь в голове
Оценка опирается на две шпаргалки. Первая — степени двойки, чтобы мгновенно переводить «сколько байт» в «сколько машин»:
2^10 ≈ 1 тысяча → 1 КБ
2^20 ≈ 1 миллион → 1 МБ
2^30 ≈ 1 миллиард → 1 ГБ
2^40 ≈ 1 триллион → 1 ТБ
2^50 ≈ 1 квадриллион → 1 ПБВторая — числа задержек Джеффа Дина: относительная цена операций, что говорит, какой шаг дизайна доминирует:
Обращение к L1-кэшу 0,5 нс
Обращение к основной памяти 100 нс (~200× медленнее L1)
Round-trip внутри ЦОД 500 000 нс (0,5 мс)
Disk seek 10 000 000 нс (10 мс — ~20× round-trip в ЦОД)
Пакет CA→Нидерланды→CA 150 000 000 нс (150 мс между регионами)Важна форма: память ~в 100 000 раз быстрее disk seek, а межрегиональный round-trip ~в 300 раз дороже внутридатацентрового. Когда дизайн говорит «и затем читает с диска на каждый запрос» или «и затем делает синхронный межрегиональный вызов», эти числа дают цену без измерений.
▸Почему это работает
Почему округлять до одной значащей цифры? Потому что входные данные сами — догадки. Ты не знаешь число пользователей до двух цифр — знаешь, что их «около 100 миллионов», а не 97,3 миллиона. Ложная точность (расчёт 6 142 QPS) создаёт иллюзию аккуратности, которую входные данные не выдержат, и замедляет арифметику. Округляй агрессивно: 86 400 секунд/сутки → 100 000 (или ~10^5); 100М пользователей → 10^8. Вся дисциплина — рассуждение на уровне порядков: ты выбираешь между «влезает на одну машину» и «нужен флот», и ошибка в 2× этот ответ не меняет. Если ошибка в 2× изменила бы дизайн — это сигнал измерять, а не прикидывать.
Разобранная оценка: спроектируй Twitter
Возьми каноническую задачу с собеседования. Допустим, 300М пользователей в месяц, 150М в день (DAU), каждый в среднем постит 2 твита/день и читает ленту так, что чтений система отдаёт куда больше, чем записей.
Write QPS. 150М × 2 твита = 300М твитов/сутки. В сутках ~86 400 секунд — округлим до 10^5 (100 000). Тогда 3×10^8 ÷ 10^5 = 3 000 записей/с в среднем. Пик резче среднего; умножим на ~3 как запас → ~10 000 записей/с на пике.
Read QPS. В соцлентах доминируют чтения — допустим отношение чтений к записям 100:1 (люди скроллят куда больше, чем постят). 3 000 × 100 = 300 000 чтений/с в среднем, ~1М на пике. Уже это одно число задаёт дизайн: 300К чтений/с не снять с одной БД, поэтому путь чтения с кэшем или fan-out-on-write (запись в хранилище сразу со всеми копиями для фидов подписчиков) обязателен — и это ты узнал до рисования первой коробки.
Объём за 5 лет. Твит — ~300 байт текста + метаданные; округлим до ~10^3 байт с запасом. 3×10^8 твитов/сутки × 10^3 байт = 3×10^11 байт/сутки = ~300 ГБ/сутки текста. За 5 лет: 300 ГБ × 365 × 5 ≈ ~550 ТБ. Медиа (картинки/видео) затмевает это — если 10% твитов несут картинку в 1 МБ, это 3×10^7 × 10^6 = 3×10^13 = ~30 ТБ/сутки, ~50 ПБ за 5 лет. Оценка только что сказала, что реальная проблема хранения — медиа, а не текст — на три порядка.
Размер кэша. Ты не кэшируешь 5 лет твитов; кэшируешь горячее. Допустим, хочешь держать горячим ~сутки твитов: 300 ГБ текста спокойно влезают в RAM на нескольких машинах (современный сервер держит 256–512 ГБ). Значит, кэш ленты дёшев; дорогая и сложная часть — хранилище медиа — и снова известно до кода.
Когда оценка меняет дизайн
Всё упражнение окупается, когда число пересекает порог. Несколько несущих порогов стоит запомнить:
- Влезает ли в RAM на одной машине? Если горячий рабочий набор < ~256 ГБ, один кэш-узел (или малый реплицированный набор) жизнеспособен; выше — кэш надо шардировать.
- Влезает ли в одну БД? Один primary спокойно держит порядка низких тысяч записей/с; десятки тысяч — значит шардинг или другой стор. Наши 10К пиковых записей — ровно на грани: это сигнал планировать шардинг сейчас, а не потом (урок из vertical-vs-horizontal: не открывай потолок во время сбоя).
- Реален ли трафик? 300К чтений/с × средний ответ 5 КБ = 1,5 ГБ/с = ~12 Гбит/с исходящего — норм по флоту, но говорит, что один NIC на 10 Гбит/с это не отдаст, и ставит реальную цифру в счёт за CDN.
Вместе эти три порога говорят, влезает ли дизайн в существующее железо, где нужен шардинг и каким будет счёт — всё это до единой нарисованной коробки архитектуры. Пропусти любой из них — и обнаружишь это в два часа ночи во время сбоя.
▸Частая ошибка
Самая частая ошибка оценки — не арифметика, а использование среднего, когда систему размеряют по пику. Средний QPS — это всего / 86 400, но трафик всплесковый: потребительское приложение видит 3–10× от суточного среднего на вечернем пике, а флеш-распродажа или вирусное событие — куда больше. Провижинь под суточное среднее — и упадёшь ровно тогда, когда это важно. Всегда неси множитель пик-к-среднему (начни с 2–3× и подстрой под домен) и помни, что ретраи во время инцидента добавляют нагрузку именно тогда, когда ты уже на пике — петля обратной связи, что превращает просадку в полный сбой.
У сервиса 100М активных в день, каждый делает 10 запросов/сутки. Оценивая до одной значащей цифры, каков средний QPS и под какой пик примерно провижинить?
Салфетка говорит, что фиче нужно ~3 000 записей/с в среднем на сторе, где один primary спокойно тянет низкие тысячи. Оценка может ошибаться в 2×. Каков верный ход?
Поскольку входы оценки сами — догадки (около 100М пользователей, а не 97,3М), каждый результат стоит округлять до одной _______ цифры — лишние разряды выдумывают точность, которую входы не выдержат, и лишь замедляют арифметику.
- 01Какие четыре величины оцениваешь и почему именно их?
- 02Пройди оценку Twitter write→read→объём до одной значащей цифры.
- 03Назови два порога, где оценка меняет дизайн, и ловушку пик-против-среднего.
Оценка на салфетке — senior-привычка решать, какой дизайн правдоподобен, до его сборки, прикидывая четыре величины — QPS, объём (спроецированный на годы), трафик и память — с точностью до порядка. Она опирается на две шпаргалки: степени двойки (2^30 ≈ 1 ГБ, так что байты мгновенно переводятся в машины) и числа задержек Джеффа Дина (память ~в 100× быстрее round-trip в ЦОД, ~в 100 000× быстрее disk seek, межрегиональный прыжок ~150 мс), что говорят, какой шаг дизайна доминирует. Всегда округляй до одной значащей цифры — входы это догадки, поэтому ложная точность это ложь — и всегда размеряйся по пику, а не по среднему (в 3–10× выше, хуже от штормов ретраев). Разобранная оценка Twitter показывает выигрыш: за две минуты вскрывается, что 300К read QPS вынуждают путь чтения с кэшем/fan-out, а хранилище медиа (~50 ПБ) затмевает текст в 100× — два меняющих дизайн факта, найденные на салфетке, а не в трёхнедельном прототипе. Теперь, когда увидишь предложение дизайна, первым делом хватай салфетку: оцени QPS, сравни с потолком одной машины, спроецируй объём — и через две минуты будешь знать, стоит ли продолжать разговор.
Практика
Начни сверху. Задачи идут от простого к сложному: вспомнить факт, применить к случаю, затем senior-уровень. Открой, попробуй, потом открой ответ.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.
Примени это
Примени этот урок в реальном проекте.