Как оценить необходимое дисковое пространство для хранения сокращенных ссылок с учетом нагрузки и времени жизни

Что проверяют

Это вопрос из system design: умеете ли вы быстро прикинуть порядок величины и не забыть накладные расходы. Точная цифра никому не нужна, важны допущения вслух и понимание, что с TTL объём перестаёт расти. Следом спрашивают, что делать с истёкшими записями и где хранить статистику переходов.

Как отвечать

Сначала зафиксируйте входные данные и проговорите их: например, 10 млн новых ссылок в сутки и срок жизни один год. Хранилище для такого сервиса на Django или FastAPI обычно PostgreSQL, от него и считаем.

• число живых записей: при постоянном потоке и TTL объём выходит на плато, равное потоку, умноженному на время жизни: 10 млн × 365 ≈ 3,65 млрд записей. Без TTL растёт линейно и бесконечно;
• размер записи: код из 7 символов base62 (62⁷ ≈ 3,5 трлн комбинаций, запас огромный), исходный URL в среднем около 100 байт, created_at, expires_at, user_id по 8 байт. Полезных данных около 150 байт;
• накладные расходы: заголовок строки в PostgreSQL около 23 байт плюс указатель на неё, B-tree индекс по коду, выравнивание и неполные страницы. Реалистично закладывать от 250 до 300 байт на запись;
• итог: 3,65 млрд × 300 байт ≈ 1,1 ТБ. Умножаем на число реплик и добавляем от 30 до 50 % запаса на WAL, бэкапы и рост.

Сильный ход: предложить проверить модель замером. Вставить миллион синтетических строк и посмотреть pg_total_relation_size('links'), это точнее любых таблиц с размерами типов.

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

Где спотыкаются

Считают только сам URL и забывают индексы, заголовки строк и репликацию. Ошибка в два-три раза для такой оценки уже существенна.

Думают, что DELETE истёкших записей сразу освобождает диск. В PostgreSQL место после VACUUM становится пригодным для повторного использования, но файлы не сжимаются. Удобнее партиционировать по дате и удалять целые партиции через DROP.

Берут цифры из воздуха без проговорённых допущений. Интервьюер ценит не результат, а то, можно ли пересчитать его, поменяв одно число.