Системный дизайн: сокращатель ссылок

Знакомая задача — новый масштаб

Ты уже писал сокращатель ссылок в проекте: таблица, генерация кода, редирект. Работает? Работает. А теперь представь, что это интервью на senior-позицию, и интервьюер говорит:

«Отлично. Теперь пусть это будет сервис уровня bit.ly: 100 миллионов ссылок в базе и 1000 RPS на чтение. Что изменится?»

Первое правило системного дизайна: не рисуй архитектуру, пока не посчитал цифры. 🧮

Функциональные требования

Нефункциональные требования

• Чтений сильно больше, чем записей. Ссылку создают один раз, а кликают тысячи раз. Типичное соотношение — 100:1.
• Редирект должен быть быстрым: < 50 мс. Это первый хоп каждого перехода.
• Доступность важнее строгой согласованности: если ссылка станет кликабельной на 100 мс позже — никто не заметит. Если редиректы лягут — заметят все.

Back-of-envelope: считаем

Записи (создание ссылок). 1000 RPS чтения при соотношении 100:1 → ~10 RPS записи. Это смешная нагрузка — любая СУБД справится одним инстансом.

Хранилище. Одна запись:

code:        7 байт
long_url:    ~200 байт (в среднем)
метаданные:  created_at, user_id, счётчик... ~100 байт
индексы:     ещё примерно столько же
─────────────────────────────
итого:       ~500 байт на ссылку

100 000 000 ссылок × 500 байт = 50 ГБ. 😲 Сюрприз: всё влезает на один сервер, даже с запасом на годы вперёд. Шардировать базу не нужно — и это важный вывод, который ты озвучиваешь интервьюеру.

Трафик редиректов. Ответ на редирект — это заголовок Location плюс мелочь, ~500 байт:

1000 RPS × 500 байт = 500 КБ/с ≈ 4 Мбит/с

Трафик копеечный. Значит, узкое место не сеть и не диск, а латентность и отказоустойчивость — вокруг этого и строим дизайн.