Генератор выдаёт уникальный идентификатор, TinyUrl сохраняет отображение ID → URL. Уникальный индекс в хранилище остаётся последней защитой от коллизий.
Создание сервиса коротких URL‑адресов
Генератор выдаёт уникальный идентификатор, TinyUrl сохраняет отображение ID → URL. Уникальный индекс в хранилище остаётся последней защитой от коллизий.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Условие
В системе используется кэш с политикой LRU, сервисы TinyUrl (POST/GET) и горизонтально масштабируемая SQL‑база с репликацией. Смоделируйте внешний сервис, отвечающий за генерацию коротких ссылок:
- Как отделить процесс получения short_link от логики сохранения и извлечения данных;
- Как гарантировать уникальность генерируемых ссылок, особенно когда генерация происходит в нескольких экземплярах сервиса;
- Как избежать гонок при записи (race conditions);
- Как синхронизировать идентификаторы или пространство имён, если генерация распределена;
- Как построить взаимодействие между TinyUrl POST и генератором ссылок (gRPC, REST и т.п.).
Ответ
Генератор выдаёт уникальный идентификатор, TinyUrl сохраняет отображение ID → URL. Уникальный индекс в хранилище остаётся последней защитой от коллизий.
Простой вариант — централизованная sequence с репликацией либо распределение непересекающихся диапазонов ID по экземплярам генератора. ID кодируют, например, в base62; потерянные неиспользованные номера допустимы и не требуют повторного использования.
TinyUrl вызывает генератор по REST/gRPC с дедлайном, затем атомарно вставляет запись. Для повторов клиентского POST сохраняется ключ идемпотентности вместе с результатом. Случайные коды — альтернативный вариант, но коллизии тогда обнаруживают UNIQUE и повторяют генерацию ограниченное число раз. Координация диапазонов должна переживать рестарты и failover без повторной выдачи уже выделенных значений.