Требования и расчёт

• Функционально: создать короткую ссылку (опционально свой алиас и TTL), перейти по ней, посмотреть статистику. Не делаем: аналитику в реальном времени, A/B, биллинг.
• Нефункционально: для чтения латентность p99 меньше 50 мс и доступность 99.99 % (редирект лежит на критичном пути), запись может быть медленнее.
• Цифры: 100 млн новых ссылок в месяц ≈ 40 записей/с; чтение к записи 100:1 → 4 000 чтений/с, пик ×4 ≈ 16 000 rps. Хранение: 500 Б на запись × 100 млн × 12 мес ≈ 600 ГБ/год - влезает в один сервер, шардинг пока не нужен. Горячие 10 % ссылок дают ~90 % трафика → кэш на 20–50 ГБ закрывает почти всё.

Генерация ключа: счётчик + base62 против хеша

Длина ключа: base62 даёт 62⁷ ≈ 3.5·10¹² - семи символов хватит на десятилетия.

На практике берут счётчик, а его узкое место снимают так: не ходить в общий счётчик на каждую ссылку, а выдавать инстансам диапазоны (range allocator: сервис берёт блок из 10 000 идентификаторов одним INCRBY в Redis или UPDATE ... RETURNING в БД и раздаёт локально). Уходит и сетевой хоп, и единая точка отказа на горячем пути. Предсказуемость лечим перемешиванием битов перед кодированием (обратимая перестановка, Feistel-шифр на 41 бите: 2 в сорок второй уже больше, чем 62 в седьмой) - ключи остаются уникальными, но перестают идти подряд. Без общего счётчика можно обойтись и вовсе, взяв Snowflake-подобный id (время + id инстанса + последовательность).

Хранилище и кэш

• Модель тривиальна: short_key PRIMARY KEY, long_url, user_id, created_at, expires_at. Доступ строго по первичному ключу, идеальный кандидат для key-value, но Postgres на 600 ГБ и 40 записях/с справится без вопросов, и начинать стоит с него.
• Кэш: Redis, ключ → URL, TTL несколько часов, LRU. Хитрейт 90+ % за счёт распределения Ципфа. При промахе идём в БД и прогреваем кэш (single-flight, чтобы 1000 параллельных запросов на один холодный ключ не устроили stampede).
• Записи иммутабельны, и это сильно упрощает жизнь: нет инвалидации кэша, можно кэшировать сколь угодно агрессивно, можно раздавать через CDN.

301 или 302 - вопрос с подвохом

301 (Moved Permanently) кэшируется браузером надолго: следующий переход пойдёт мимо твоего сервиса. Меньше нагрузки, но ты теряешь статистику кликов и не можешь изменить или отозвать ссылку - браузер уже никогда не спросит. 302 (Found) не кэшируется: каждый переход приходит к тебе, статистика полная, ссылку можно отключить. Правильный ответ: 302 по умолчанию, потому что бизнес-ценность продукта держится на статистике и управлении ссылками; 301 остаётся опцией для тех, кому нужна максимальная скорость и не нужна аналитика. Отдельная тонкость: для редиректа корректнее 307/308, если важно сохранить метод и тело запроса, но для ссылок это несущественно.

Счётчики кликов

Инкремент строки в БД на каждый клик убивает сервис на первой же горячей ссылке. Правильный путь: редирект отвечает сразу, а событие клика уходит в брокер; отдельный потребитель агрегирует и пишет в аналитическое хранилище (ClickHouse) или инкрементит счётчик в Redis с периодическим сбросом в БД. Точность «примерно» здесь допустима, и это надо проговорить как осознанный выбор.

Требования

• Ограничивать по разным ключам: API-ключ, user_id, IP, эндпоинт, и по комбинациям. Разные лимиты для разных тарифов.
• Проверка должна укладываться в единицы миллисекунд, иначе лимитер сам станет узким местом.
• Точность: «примерно» приемлемо; распределённый лимитер, который гарантирует строгое «не более 100», требует согласования и стоит дороже, чем польза.
• Ответ при превышении: 429 плюс заголовки X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset и Retry-After - без них клиенты будут долбить в цикле.

Алгоритмы

Практический выбор: token bucket, если хочется разрешать короткие всплески (нормальное поведение реальных клиентов), sliding window counter, если важна предсказуемость. Оба делаются в Redis двумя-тремя полями и Lua-скриптом.

# token bucket в Redis: атомарно через Lua (иначе гонка между GET и SET)
# KEYS[1] = bucket:user:42 ; ARGV = rate, capacity, now, cost
# HMGET tokens last_refill -> долить (now-last)*rate, обрезать по capacity
# если tokens >= cost: списать, вернуть 1 ; иначе вернуть 0 и время до пополнения
EVALSHA <sha> 1 bucket:user:42 10 100 1730000000 1

Архитектура

• Где принимается решение. На gateway/edge - как можно раньше, чтобы отброшенный запрос не тратил ресурсы. Отдельный «сервис лимитера» добавляет сетевой хоп и на горячем пути только вредит; лучше библиотека внутри gateway плюс общий Redis.
• Локальный слой + глобальный. Каждый инстанс держит локальный счётчик и синхронизируется с Redis не на каждом запросе, а пачками или по «квоте» (инстанс берёт из общего лимита долю и расходует локально). Сетевой вызов уходит из горячего пути ценой небольшой неточности.
• Хранилище. Redis (в идеале рядом, в том же регионе). Для мультирегиона держат лимиты по регионам, а не глобальный счётчик: кросс-региональная синхронизация на каждый запрос невозможна по латентности.
• Конфигурация лимитов меняется динамически, без релиза: правила в конфиг-сервисе с горячей перезагрузкой, потому что лимиты меняют чаще, чем код.

Расчёт, который определяет выбор

• 10 млн DAU, каждый заходит 10 раз в день → ~1 200 чтений ленты/с, пик ×4 ≈ 5 000.
• Постов: 1 млн в день → ~12 записей/с. Соотношение чтение/запись ≈ 100:1, значит, оптимизировать надо чтение.
• Средний подписчик: 200 фолловеров. При fanout on write один пост порождает 200 вставок → 12 × 200 = 2 400 вставок/с - вполне подъёмно.
• А теперь знаменитость с 50 млн подписчиков: один твит = 50 млн вставок. При 10 000 вставок/с это полтора часа на один пост, и всё это время часть подписчиков его не видит. Вот здесь чистый push и ломается.
• Хранение лент: 10 млн активных × 500 записей × 100 Б ≈ 500 ГБ в Redis - дорого, поэтому материализуют ленту только для активных пользователей (заходил за последние N дней) и ограничивают глубину.

Гибрид в деталях

1. Порог, скажем, 10 000 подписчиков. Ниже него работает fanout on write в Redis-список feed:{user_id} (обрезанный до 500–1000 записей, хранятся только id постов).
2. Выше порога не разносим вообще. При чтении: берём готовую ленту, отдельно читаем свежие посты тех знаменитостей, на кого подписан читатель (их обычно единицы-десятки и они прекрасно кэшируются), сливаем по времени/ранжированию.
3. Fanout выполняется асинхронно воркерами из очереди, публикация поста не ждёт разноса. Для активных подписчиков приоритет выше: те, кто онлайн, получают пост за секунды, остальные - за минуты.
4. Материализуем ленты только активных пользователей. Для вернувшегося через полгода лента собирается на лету и потом материализуется.

Дополнительные вопросы, которые почти всегда задают

• Удаление поста. Из миллионов лент его не вычищают, а фильтруют при чтении по «удалённым» (проверка id по множеству удалённых или по флагу в кэше постов).
• Ранжирование вместо хронологии. Тогда лента собирается из кандидатов и скоринга на чтении, и push вырождается в «список кандидатов», а не в готовую ленту.
• Согласованность. Лента eventual по определению: подписался - новые посты появятся, старые подтянутся отдельным процессом. Это нормально, и это надо назвать компромиссом, а не багом.
• Хранилище постов берут key-value или шардированное по post_id; ленты живут в Redis; связи подписок лежат отдельно, шардированные по follower_id для «на кого подписан» и по followee_id для «кто подписан» (две денормализованные таблицы, потому что нужны оба направления).

Транспорт

• WebSocket берут по умолчанию: двунаправленно, низкие накладные, работает через браузер. Альтернативы: SSE (только сервер→клиент, зато проще и переживает прокси), long polling (fallback), для мобильных - пуш-каналы (APNs/FCM), когда приложение в фоне и соединение держать нельзя.
• Слой соединений отдельный от бизнес-логики. Gateway держит сокеты и не знает домена; логика - в сервисах. Так логику можно деплоить, не рвя миллионы соединений.
• Реестр присутствия: user_id → gateway_id в Redis с TTL, обновляется heartbeat. Чтобы доставить сообщение, сервис смотрит реестр и шлёт на нужный gateway (напрямую или через топик/канал по gateway_id).
• Масштаб: одна Go-машина спокойно держит сотни тысяч соединений (~2–10 КБ на соединение при аккуратных буферах), так что 10 млн онлайна закрываются десятками узлов, а не тысячами. Узкое место обычно не CPU, а память под буферы и количество файловых дескрипторов.

Путь сообщения и подтверждения

1. Клиент отправляет сообщение с собственным client_msg_id (UUID), и это ключ идемпотентности: повтор после обрыва не создаст дубль.
2. Сервис сначала персистит сообщение и присваивает ему серверный порядковый номер seq в пределах диалога, потом отвечает отправителю ack: sent. Порядок «сохранить → подтвердить» принципиален: подтверждать до записи - значит терять сообщения при падении.
3. Дальше доставка получателям. Онлайн идёт через gateway, а для оффлайна сообщение просто лежит в истории, и клиент заберёт его при следующем подключении по своему last_seen_seq.
4. Получатель присылает delivered, при открытии чата - read. Оба статуса тоже сообщения, и они тоже могут потеряться, поэтому хранятся как «максимальный подтверждённый seq на пользователя», а не как флаг на каждом сообщении: так они идемпотентны и компактны.

Хранение истории

• Паттерн доступа один: «последние N сообщений чата» и «сообщения чата после seq». Это идеальный кандидат для wide-column хранилища: ключ партиции chat_id, кластеризация по seq DESC (Cassandra/ScyllaDB) или Postgres, шардированный по chat_id, с партиционированием по времени.
• Расчёт: 10 млн DAU × 50 сообщений/день = 500 млн сообщений/день × 300 Б ≈ 150 ГБ/день. Значит, нужны политика хранения (горячие последние месяцы, холодное - в дешёвое хранилище) и обязательное партиционирование по времени, чтобы удалять срезанием партиций, а не DELETE.
• Медиа не хранятся в БД: файл в S3, в сообщении - ссылка и метаданные.
• Групповые чаты: не копировать сообщение каждому участнику (fanout on write), а хранить один раз в чате и держать на пользователя только курсор прочитанного. Копирование оправдано только при малом размере групп и жёстком требовании к скорости чтения.

Онлайн-статусы

Самая недооценённая часть: наивное «рассылать всем контактам при каждом изменении» даёт квадратичный трафик. На практике: статус в Redis с коротким TTL, обновляемый heartbeat; рассылка изменений только тем, кто сейчас смотрит на этого пользователя (открыт чат или список); агрегация и throttling («не чаще раза в 10–30 секунд»); «был в сети недавно» с огрублением вместо точной секунды, что и дешевле, и приватнее.

Компоненты

1. Приём. API или подписка на события домена. Вход всегда несёт event_id для дедупликации и user_id.
2. Движок правил / preferences. Решает, каким каналам слать (push, email, SMS, in-app, webhook), и смотрит на подписки пользователя, отписки, язык, часовой пояс, тихие часы и глобальные настройки типа уведомления. Здесь же живут отписка и юридические требования: для email ссылка отписки обязательна.
3. Шаблонизатор. Отдельно от логики: текст, локализация, версии шаблонов. Шаблон в коде обернётся болью при первой же правке маркетологом.
4. Очереди по каналу и приоритету. Транзакционные («код подтверждения», «платёж не прошёл») идут в отдельную очередь с высоким приоритетом; маркетинговые в свою, и её можно тормозить или дропать при перегрузке.
5. Воркеры-адаптеры к провайдерам (APNs, FCM, SMTP/SES, SMS-агрегатор). У каждого свой пул (bulkhead), свой rate limit под квоту провайдера, свой circuit breaker.
6. Трекинг. Статусы: queued → sent → delivered → opened → failed, вебхуки от провайдеров, отдельная обработка «жёстких» отказов: по невалидному токену удаляем устройство, по bounce email помечаем адрес.

Надёжность и дедупликация

• Ретраи с экспонентой и jitter, разные политики по каналам: push дешёвый - можно повторять активно; SMS стоит денег, поэтому число попыток ограничено, а лимит расходов обязателен.
• Ключ дедупликации = (user_id, event_id, channel) в Redis/БД с TTL. Без него at-least-once доставка событий превращается в «пять одинаковых пушей подряд», и это самая заметная пользователю поломка.
• Дедупликация по смыслу, не только по id: «10 человек лайкнули ваш пост» сворачивается в одно уведомление в окне (например, 15 минут) вместо десяти пушей. Требование продуктовое, но живёт в этой же системе.
• Rate limit на пользователя: не больше N уведомлений в час независимо от того, сколько событий произошло. Защищает и пользователя, и репутацию отправителя.
• DLQ для окончательно неудавшихся: оттуда их можно разобрать и отправить заново.

Тихие часы и планирование

Тихие часы считаются в часовом поясе пользователя, а не сервера. На этом ошибаются постоянно. Внутри окна тихих часов уведомление не выбрасывается, а откладывается до открытия окна (это ровно задача планировщика отложенных задач из вопроса 9). Транзакционные и security-уведомления («вход с нового устройства») проходят всегда, и список исключений задаётся типом уведомления, а не отдельным флагом на каждом сообщении.

Отдельная тонкость масштаба: массовая рассылка на 10 млн пользователей не уходит одним залпом. Её разбивают на пачки и притормаживают (и по квоте провайдера, и по нагрузке на свои сервисы, потому что после пуша все эти люди одновременно откроют приложение, а вторичный пик на бэкенде часто больше, чем сама рассылка).

Загрузка

1. Клиент запрашивает POST /uploads с именем, размером, типом и (желательно) хешем содержимого.
2. Бэкенд проверяет права, квоту, лимит размера и допустимый тип, создаёт запись метаданных со статусом PENDING и выдаёт presigned URL с коротким TTL (минуты) и жёсткими условиями: конкретный ключ объекта, Content-Type, размер. Потолок «не больше N байт» в S3 ставит только presigned POST (условие content-length-range в политике), а presigned PUT умеет лишь зашить в подпись точный размер, заявленный клиентом.
3. Клиент заливает напрямую в S3. Твои серверы не видят ни байта - это экономит трафик, память и снимает проблему «файл на 5 ГБ через Go-хендлер».
4. Подтверждают двумя способами: либо клиент дергает POST /uploads/{id}/complete, либо (надёжнее) бэкенд слушает событие от хранилища о появлении объекта. Второе устойчиво к тому, что клиент закрыл вкладку. Статус переходит в READY.
5. Фоном: антивирус, извлечение метаданных, превью и транскодирование. Всё через очередь, не в момент загрузки.
6. Уборка мусора: объекты, оставшиеся в PENDING дольше суток, удаляются (lifecycle policy в бакете + сверка с метаданными). Без этого хранилище копит недозагруженные файлы, за которые ты платишь.

Большие файлы: чанки

• Multipart upload: файл режется на части (обычно 5–100 МБ), каждая заливается по своему presigned URL, в конце вызывается complete со списком частей и их ETag.
• Что это даёт: возобновление после обрыва (перезалить одну часть, а не весь файл), параллельность (несколько частей одновременно, на длинных RTT это заметно быстрее), обход лимита на размер одного запроса.
• Клиент хранит состояние загрузки (какие части уже приняты), чтобы после перезапуска продолжить. Незавершённые multipart-загрузки тоже надо чистить политикой жизненного цикла, иначе за них капает счёт.

Дедупликация по хешу

Считаем SHA-256 содержимого (на клиенте, тогда можно вообще не заливать, или на сервере при обработке). Ключ объекта = хеш, метаданные ссылаются на него. Если файл с таким хешем уже есть, загрузка проходит мгновенно, место не тратится. Три обязательные оговорки: (1) нужен счётчик ссылок или отложенное удаление, иначе один пользователь удалит файл и сломает его у другого; (2) «мгновенная загрузка» по хешу без проверки владения открывает уязвимость: зная хеш, можно получить чужой файл, поэтому доступ проверяется по метаданным, а не по факту совпадения хеша; (3) если клиент шифрует файлы своим ключом, дедупликация не работает: одинаковые файлы превращаются в разный шифротекст. Ключ, выведенный из хеша самого файла, это обходит, но тогда сервер видит, что у двух людей один и тот же файл.

Раздача

• CDN перед хранилищем: файлы иммутабельны (ключ содержит хеш или версию), поэтому кэшируются вечно с Cache-Control: public, max-age=31536000, immutable. Обновление файла = новый ключ, а не инвалидация.
• Приватный контент раздаётся подписанными URL от CDN с коротким TTL и (для важного) привязкой к IP или подписью в куке. Не «секретная неугадываемая ссылка», если контент действительно приватный: такие ссылки утекают через реферер, мессенджеры и историю.
• Range-запросы для видео и докачки, ETag/If-None-Match для условных запросов.
• Стоимость: исходящий трафик обычно самая дорогая строка счёта. CDN берут ради скорости, но окупается он тем, что кэш-хит дешевле обращения к хранилищу.

Требования и расчёт

• p99 меньше 50–100 мс, иначе подсказки не успевают за печатью и бесполезны.
• Нагрузка обманчиво большая: 10 млн поисков в день × ~5 нажатий = 50 млн запросов в день ≈ 600 rps средних, пик ×5 ≈ 3 000. Debounce 100–150 мс на клиенте режет это в 2–3 раза бесплатно.
• Свежесть: для большинства запросов обновление раз в час-сутки нормально; для трендов («новость дня») нужен отдельный быстрый путь.

Структура данных

• Trie. Путь по дереву соответствует префиксу. Наивный вариант «дойти до узла и обойти всё поддерево» слишком медленный: у популярного префикса «а» миллионы листьев.
• Трюк, который и есть ответ: в каждом узле заранее хранится готовый топ-K (K = 5–10) завершений с их весами. Тогда запрос сводится к спуску по префиксу за O(len(prefix)) и возврату готового списка. Память растёт (K строк в каждом узле), зато чтение становится тривиальным.
• Сжатие: radix tree уменьшает число узлов в разы; для очень больших словарей берут succinct-структуры или FST (так устроен Lucene).
• Где живёт: целиком в памяти сервиса, реплики читают одну и ту же иммутабельную версию. Альтернатива без trie: Redis sorted set на префикс (ZRANGE pfx:{prefix} 0 9 REV) - проще в эксплуатации, но памяти больше и обновлять тяжелее.

Обновление

1. Логи запросов → агрегация за окно (час/сутки) в частоты → фильтрация (стоп-слова, мат, персональные данные, редкие «хвосты», запросы с нулевым результатом) → пересборка структуры.
2. Пересобирать целиком и подменять атомарно, а не мутировать на месте: новая версия trie строится офлайн, выкатывается на реплики, переключается указателем. Это снимает все проблемы блокировок и даёт мгновенный откат.
3. Веса считаются не по одной частоте: свежесть (экспоненциальное затухание старых периодов), персонализация и география ложатся отдельными слоями поверх базового топа, чтобы не пересобирать всё под каждого пользователя.
4. Тренды держат в отдельном маленьком «горячем» слое в Redis, который сливается с основным результатом на чтении. Свежесть появляется без пересборки основной структуры.

Кэш и клиент

• Кэш префиксов на стороне сервиса: короткие префиксы (1–3 символа) дают подавляющую долю запросов и почти не меняются, поэтому их ответы кэшируются с большим TTL. Распределение резко Ципфовское, и небольшой кэш даёт очень высокий хитрейт.
• На клиенте: debounce (не слать на каждый символ), отмена предыдущего запроса, локальный кэш уже полученных префиксов (пользователь набрал «моск», а ответ для «мос» у клиента уже есть, и он отфильтрует локально), плюс подстраховка от гонки: ответы приходят не в том порядке, и показывать надо только ответ на актуальный префикс.

Модель: платёж - конечный автомат

CREATE TABLE payments (
    id              uuid PRIMARY KEY,
    idempotency_key text        NOT NULL,
    user_id         bigint      NOT NULL,
    amount          bigint      NOT NULL,        -- только целые: копейки/центы
    currency        char(3)     NOT NULL,
    state           text        NOT NULL,        -- CREATED|AUTHORIZED|CAPTURED|FAILED|REFUNDED
    provider_ref    text,                        -- id операции на стороне провайдера
    version         int         NOT NULL DEFAULT 0,
    created_at      timestamptz NOT NULL DEFAULT now(),
    updated_at      timestamptz NOT NULL DEFAULT now(),
    UNIQUE (user_id, idempotency_key)            -- защита от двойного создания
);

Три вещи, которые надо сказать про модель. Деньги считаем целым числом в минимальных единицах: float для денег сразу поднимает красный флаг. Переходы только вперёд и только условные: UPDATE ... WHERE id=$1 AND state='CREATED' делает повторы идемпотентными. Двойная запись для баланса: серьёзные системы хранят не «баланс», а неизменяемый журнал проводок и выводят баланс из него. Тогда история восстановима и расхождения ловятся арифметикой.

Поток

1. Вход: POST /payments с Idempotency-Key. Повтор с тем же ключом возвращает тот же платёж, а не создаёт новый. Ключ и платёж создаются одной транзакцией.
2. Только вызов провайдера неидемпотентен изначально. Передаём провайдеру свой ключ идемпотентности (нормальные провайдеры это поддерживают), сохраняем provider_ref.
3. Неопределённость. Если ответ не пришёл, нельзя считать платёж неуспешным: он мог пройти. Состояние остаётся «в процессе», и стартует опрос статуса у провайдера по своему ключу, пока тот не ответит определённо.
4. Вебхуки от провайдера подтверждают операцию асинхронно. Обязательно: проверить подпись, дедуплицировать по id события, обработать идемпотентно и выдержать любой порядок (вебхук «captured» может прийти раньше, чем ответ на исходный запрос).
5. Outbox: смена состояния платежа и событие для остальной системы (payment.captured) пишутся одной транзакцией; релей публикует в брокер. Никаких прямых вызовов «сообщить сервису заказов» из транзакции.
6. Сага для составных сценариев («оплата + резерв товара + бонусы»): оркестратор с персистентным состоянием, компенсации (возврат оформляется новой операцией, а не откатом), необратимые шаги в конце.

Сверка (reconciliation) - обязательная часть, а не опция

Любая распределённая система рано или поздно расходится с внешним контуром. Ежедневный (а для крупных - ежечасный) процесс выгружает реестр операций провайдера и сравнивает с собственной базой по трём признакам: есть у нас - нет у них (мы считаем платёж успешным, а денег нет), есть у них - нет у нас (деньги списаны, а заказ не создан - самое опасное), суммы или статусы различаются. Расхождения попадают в отдельную очередь ручного разбора со своим SLA. Кто называет сверку без подсказки, тот с деньгами работал, а не читал про них.

Требования, от которых зависит выбор

• Точность: «примерно через час» (планировщик раз в минуту) или «ровно в 12:00:00.000» (таймер в памяти). Разница в стоимости на порядок.
• Горизонт: минуты, дни или годы вперёд (напоминания, подписки).
• Объём: тысячи задач или сотни миллионов «висящих» одновременно.
• Гарантии: at-least-once (норма) или дубли недопустимы; переживает ли задача рестарт; можно ли её отменить и перепланировать.
• Профиль: равномерно или пиками (всё на «ровно 9:00» случается очень часто и ломает наивные реализации).

Три подхода

Есть ещё готовые механизмы брокеров: delayed exchange в RabbitMQ, DLX с TTL, SQS DelaySeconds (до 15 минут), scheduled messages в Pulsar. Они удобны для коротких задержек и плохи для длинных горизонтов и для отмены - сообщение, уже лежащее в очереди с задержкой, обычно нельзя ни отменить, ни перепланировать.

Детали, за которые ставят плюс

• Claim с TTL, а не просто статус. Забирая задачу, воркер пишет claimed_until = now() + interval '5 min'; фоновый процесс возвращает в SCHEDULED всё, у чего срок истёк. Иначе упавший воркер забирает задачу с собой навсегда.
• Идемпотентность выполнения обязательна: гарантия at-least-once, и при неудачном подтверждении задача выполнится дважды.
• Ретраи с экспонентой и DLQ: неуспешная задача перепланируется на now() + backoff, после N попыток уходит в DLQ с алертом.
• Пик на круглое время. Все задачи на «ровно 9:00» создают всплеск, который положит и БД, и потребителей. Лечат это jitter при планировании (размазать по окну ±N минут, если бизнес позволяет) и ограничением скорости выдачи задач воркерам.
• Партиционирование по run_at: старые выполненные партиции отрезаются мгновенно вместо тяжёлого DELETE; индекс по run_at делают частичным, только по state='SCHEDULED', чтобы он оставался маленьким при миллиардах выполненных задач.
• Точность против масштаба, названная явно: опрос БД раз в секунду даёт точность ±1 с и нагрузку 1 запрос/с - для 99 % задач этого достаточно. Точность в миллисекунды требует таймеров в памяти и, значит, механизма восстановления после рестарта. Требовать точность выше необходимой значит заниматься оверинжинирингом, и про это стоит сказать вслух.

Правильная структура ответа

1. Сначала уточнить, x10 чего. Чтений, записей, объёма данных или числа пользователей? Это совершенно разные проблемы: x10 чтений лечится кэшем и репликами почти бесплатно, x10 записи упирается в шардинг или смену хранилища, x10 объёма - в партиционирование и архивацию.
2. Посмотреть на измерения, а не гадать. «Открою дашборд и посмотрю, где насыщение: CPU, диск, пул соединений, лаг очереди, лаг репликации». Ответ «сначала измерю» на этом вопросе всегда правильный.
3. Дальше по возрастанию стоимости:
   • Кэш и индексы обходятся дешевле всего. Один пропущенный индекс часто даёт те самые 10× без единой новой машины.
   • Вертикально: просто увеличить машину. Скучно, но до определённого размера дешевле любой переработки архитектуры, и зрелость как раз в том, чтобы это признать.
   • Горизонтально stateless-слой, то есть добавить реплик приложения за балансировщиком. Работает, только если приложение действительно stateless.
   • Реплики для чтения, обязательно с оговоркой про лаг и read-your-writes.
   • Вынести тяжёлое в асинхронный контур: всё, что не нужно клиенту для ответа, уезжает в очередь. Часто это даёт больше, чем новое железо.
   • Шардинг идёт последним и стоит дороже всего: выбор ключа, ребалансировка, кросс-шардовые запросы, распределённые транзакции. Назвать ключ и его недостатки обязательно.
4. Назвать, что не масштабируется: единственный лидер БД на запись; горячий ключ или горячая партиция; глобальный счётчик/последовательность; блокировки на популярной строке; внешний провайдер с жёсткой квотой; кросс-шардовые транзакции и джойны; всё, что требует глобального порядка.
5. Не забыть про деньги и эксплуатацию. x10 нагрузки превращается в x10 счёта, если ничего не оптимизировать. Иногда правильный ответ звучит как «сжать данные, удалить старое, поднять хитрейт кэша», а не «купить в 10 раз больше серверов».

Список кандидатов по частоте

1. База данных. Сначала не «падает», а деградирует: растёт время запросов, копятся блокировки, забивается пул соединений, растёт лаг репликации. Подкатегории: одна горячая строка (счётчик, баланс), длинные транзакции, отсутствующий индекс, автовакуум не успевает.
2. Пул соединений. Очень частый и неочевидный первый рубеж: приложение масштабируется горизонтально, каждый инстанс держит 50 соединений, на 20 инстансов выходит 1000, а БД держит 500. Дальше все ждут в очереди за соединением, и латентность взрывается при свободных CPU.
3. Кэш. Не сам Redis, а хитрейт: когда объём данных растёт, горячее множество перестаёт помещаться, хитрейт падает с 95 % до 80 %, и нагрузка на БД учетверяется при том же трафике. Самая коварная нелинейность в системе.
4. Внешние зависимости с квотой: платёжный провайдер, SMS-шлюз, геокодер. Их лимит не растёт вместе с тобой.
5. Диск. IOPS и место: логи, WAL, временные файлы сортировок. Кончилось место под WAL - БД встала целиком: классическая причина полной остановки.
6. Единственные по природе компоненты: лидер кластера, шедулер, воркер, который «почему-то один», глобальный счётчик.
7. Сеть и балансировщик: лимит соединений, полоса, число портов при NAT.

Как отвечать, чтобы это звучало как опыт

Не перечислять список, а разобрать свою схему: «в этой системе первым сдастся мастер БД: при 5 000 rps записи по 3 индексам на таблицу мы упрёмся в IOPS; увижу я это по росту p99 времени коммита и по длине очереди в пуле соединений; следом деградирует всё, что делит с ней пул, потому что таймауты начнут копить горутины». То есть: компонент → метрика → следствие.

Чек-лист по схеме