Проектирование системы сокращения URL-адресов: как работают сокращатели ссылок

«Спроектируй сокращатель URL» — один из самых популярных вопросов на собеседованиях по проектированию систем — и не без причины. Он затрагивает хеширование, базы данных, кеширование, балансировку нагрузки и распределённые системы, всё в обманчиво простом продукте.

В этом руководстве мы разберём, как на самом деле работают сокращатели URL-адресов, ключевые решения при проектировании и компромиссы, связанные с масштабированием.

Базовый поток

Сокращатель URL выполняет две функции:

1. 1
   Сокращение: возьми длинный URL и сгенерируй короткий код
2. 2
   Перенаправление: когда кто-то посещает сокращённый URL, перенаправь его на оригинальный

Вот высокоуровневый поток:

Пользователь создаёт короткую ссылку:
  Длинный URL → Генерируем короткий код → Сохраняем соответствие → Возвращаем короткий URL

Пользователь кликает на короткую ссылку:
  Короткий URL → Ищем код → Находим длинный URL → Перенаправление 301

Генерация коротких кодов

Основная задача — генерировать уникальные короткие коды. Существует несколько подходов:

Подход 1: кодирование Base62

Преобразуй автоинкрементирующийся ID в строку Base62, используя символы [a-zA-Z0-9]:

• ID 1 → 1
• ID 62 → 10
• ID 238,328 → ZZZ

7-символьный код Base62 поддерживает 62^7 = 3,5 триллиона уникальных URL-адресов.

Преимущества: просто, предсказуемая длина, без коллизий Недостатки: последовательные ID предсказуемы (пользователи могут угадать другие короткие URL)

Подход 2: хеширование

Применяем функцию хеширования (MD5, SHA-256) к длинному URL и берём первые N символов:

SHA256("https://example.com/very/long/url") → "a3f2b8c1..." Короткий код: "a3f2b8c"

Преимущества: один и тот же вход всегда дает один и тот же результат (дедупликация) Недостатки: коллизии хешей требуют обработки; фиксированная длина хеша может приводить к потере пространства

Подход 3: случайная генерация

Генерируем случайную буквенно-цифровую строку и проверяем уникальность:

Преимущества: просто, непредсказуемо Недостатки: требует проверки коллизий при каждом создании; замедляется по мере заполнения базы данных

Какой подход использовать?

Большинство production-систем используют кодирование Base62 с распределённым генератором ID. Это просто, без коллизий и производительно. В Linkly мы используем похожий подход — ты можешь прочитать больше о том, как работают сокращатели URL для менее технического обзора.

Проектирование базы данных

Основная таблица несложная:

urls ├── id (первичный ключ, автоинкремент) ├── short_code (уникальный индекс) ├── long_url (адрес назначения) ├── created_at (временная метка) ├── user_id (кто его создал) └── click_count (денормализованный счётчик)

SQL vs. NoSQL

SQL (PostgreSQL, MySQL): соответствие ACID, строгая согласованность, хорошо для средних масштабов. Большинство сокращателей URL начинают отсюда.

NoSQL (DynamoDB, Cassandra): лучшее горизонтальное масштабирование для миллиардов URL-адресов. Итоговая согласованность приемлема для этого варианта использования.

Гибридный подход: SQL для соответствий URL (нужна строгая согласованность для перенаправлений), NoSQL или база данных временных рядов для аналитики кликов (высокий объём записей, итоговая согласованность в порядке).

Обработка перенаправлений

Когда пользователь кликает на короткую ссылку, система должна:

1. 1
   Распарсить короткий код из URL
2. 2
   Найти соответствующий длинный URL
3. 3
   Вернуть ответ перенаправления HTTP

301 vs. 302 перенаправления

• 301 (постоянное): браузер кеширует перенаправление. Меньше запросов к серверу, но теряется видимость повторных кликов.
• 302 (временное): браузер проверяет с сервером каждый раз. Больше запросов, но лучше отслеживание кликов.

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

Кеширование

Перенаправления должны быть быстрыми — каждая миллисекунда задержки влияет на опыт пользователя. Кеширование критично:

In-Memory кеш (Redis/Memcached)

Кешируем соответствие короткий_код → длинный_URL в памяти:

GET /abc123 → Проверяем Redis на "abc123" → Попадание в кеш? Возвращаем перенаправление немедленно → Промах кеша? Запрашиваем БД, кешируем результат, возвращаем перенаправление

Небольшой экземпляр Redis может кешировать миллионы соответствий URL. Так как большинство трафика идёт на относительно небольшое число популярных ссылок, процент попаданий в кеш выше 90% — норма.

CDN кеширование

Для 301 перенаправлений узлы edge сети CDN могут кешировать ответ перенаправления, обслуживая его из ближайшего к пользователю местоположения без обращения к оригинальному серверу.

Аналитика и отслеживание кликов

Запись данных кликов — это операция с высоким объёмом записей, которая не должна замедлять перенаправление:

Асинхронная обработка

1. 1
   Пользователь кликает на короткую ссылку
2. 2
   Система немедленно возвращает перенаправление
3. 3
   Событие клика отправляется в очередь сообщений (Kafka, RabbitMQ, SQS)
4. 4
   Фоновый рабочий обрабатывает событие: распарсивает user agent, геолоцирует IP, сохраняет аналитику

Это разделяет быстрый путь перенаправления от более медленного конвейера аналитики.

Данные для захвата

• Временная метка
• IP-адрес (для геолокации)
• User agent (для определения устройства/браузера)
• Заголовок referrer
• Страна, город (из геолокации IP)

Соображения о масштабировании

Рабочая нагрузка, сфокусированная на чтение

Сокращатели URL — крайне ориентированы на чтение. Типичное соотношение может быть 100:1 чтений к записям. Это означает:

• Оптимизируй путь перенаправления превыше всего
• Используй кеширование агрессивно
• Читай реплики для базы данных

Распределённая генерация ID

Если ты используешь автоинкрементирующиеся ID на нескольких серверах, тебе нужно избежать коллизий. Опции:

• Snowflake IDs: подход Twitter — встроь временную метку, ID машины и номер последовательности
• UUID: универсально уникален, но длиннее
• Диапазоны ID: назначь каждому серверу диапазон ID для выделения

Географическое распределение

Развертывай серверы перенаправления в нескольких регионах. Пользователь в Токио не должен делать кругосветный trip на сервер в Виргинию для перенаправления.

Соображения безопасности

Сокращатели URL можно использовать во вред для фишинга и распространения вредоноса. Production-системы должны иметь:

• Сканирование URL — проверяй адреса назначения по базам данных вредоноса и фишинга
• Ограничение частоты — предотврати массовое создание вредоносных коротких ссылок
• Сообщение об абузе — позволь пользователям сообщить о подозрительных ссылках
• Страницы предпросмотра — опционально показывай пользователям, куда идёт ссылка перед перенаправлением

Узнай больше о безопасности ссылок и защите от click fraud.

Дополнительные функции

Помимо базового сокращения и перенаправления, production сокращатели URL добавляют:

• Собственные домены — фирменные короткие ссылки, используя твой собственный домен
• Собственные слаги — выбери свой собственный короткий код вместо случайных символов
• Истечение — ограниченные по времени ссылки, которые перестают работать после даты
• Защита паролем — требуй пароль для доступа к адресу назначения
• A/B тестирование — чередуй между несколькими адресами назначения
• Геотаргетинг — перенаправляй по стране
• Таргетинг по устройству — разные адреса назначения для мобильных vs. десктопных
• QR коды — генерируй сканируемые коды для любой короткой ссылки

Заключение

Проектирование системы сокращения URL — отличное упражнение, потому что оно начинается просто, но раскрывает слои сложности: генерация кодов, проектирование БД, кеширование, конвейеры аналитики и предотвращение абуза. Понимание этих основ помогает, работаешь ли ты над подготовкой к собеседованиям или разрабатываешь собственные инструменты.

Хочешь использовать production сокращатель URL без построения своего? Начни с Linkly — вся архитектура, описанная выше, готова к использованию с собственными доменами, аналитикой и расширенными функциями.