Спроектируйте сервис сокращения ссылок наподобие bit.ly: генерация короткого кода, редирект, статистика переходов.
Короткий ответ
- Уточнить нагрузку: чтений на порядки больше, чем записей
- Короткий код — base62 от счётчика или случайный ключ
- Хранилище ключ-значение: код → длинный URL
- Редирект 301/302, горячие ссылки держим в кэше
- Шардирование по коду при росте объёма
- Коллизии решаем повторной генерацией или диапазонами счётчика
- Статистику пишем асинхронно через очередь
Сокращатель — это key-value хранилище с base62-кодами, кэшем на чтение и асинхронным сбором статистики.
Как сказать вслух
пример ответаСначала я уточню масштаб: сколько ссылок создаётся и сколько редиректов в секунду. Дальше предложу base62-код от счётчика и key-value хранилище, а чтения закрою кэшем. Статистику уведу в очередь, чтобы редирект оставался быстрым.
Подробный ответ
Основной ответ
Начинаем с оценок: допустим, сотни записей и десятки тысяч чтений в секунду — система read-heavy. Код генерируем как base62 от монотонного счётчика (6-7 символов хватает на миллиарды ссылок) либо случайно с проверкой коллизий. Хранилище — key-value (DynamoDB, Cassandra, либо Postgres с шардированием по коду). Редирект отдаёт 302, если нужна статистика, или 301 для кэширования браузером. Горячие коды кладём в Redis, типичный hit rate высокий из-за степенного распределения популярности. Клики публикуем в Kafka и агрегируем офлайн. Счётчик масштабируем выдачей диапазонов идентификаторов каждому инстансу.
Ключевые моменты
- Генерация кода. Base62 от счётчика даёт короткие уникальные коды без проверок; диапазоны счётчика раздаются инстансам, чтобы не было единой точки отказа.
- 301 против 302. 301 кэшируется браузером и экономит трафик, но ломает подсчёт кликов; 302 держит каждый переход на сервере.
- Кэширование чтений. Redis перед базой закрывает основную нагрузку: популярные ссылки составляют малую долю ключей, но большую долю трафика.
- Асинхронная аналитика. Клик пишется в очередь, агрегаты считаются отдельным потребителем — редирект не ждёт запись в аналитическую базу.
Практический контекст
Интервьюер смотрит, начали ли вы с требований и цифр, а не с рисования квадратиков. Хорошие уточняющие вопросы: нужен ли кастомный алиас, TTL ссылок, статистика в реальном времени или достаточно суточных агрегатов, есть ли требование скрывать перебор кодов. Отдельный плюс — обсудить, что будет при падении кэша и как чистить просроченные ссылки.
Частые ошибки
- Начинают рисовать архитектуру, не уточнив нагрузку и соотношение чтений к записям
- Предлагают MD5/SHA от URL целиком и не объясняют, как обрезка хэша порождает коллизии
- Забывают про статистику и выбирают 301, после чего переходы перестают доходить до сервера