Запрос проходит авторизацию и лимиты, получает уникальный код, затем атомарно сохраняется в нужном шарде. Глобальная блокировка всех создаваемых ссылок не нужна и станет узким местом.
Проектирование полного процесса создания короткой ссылки (POST flow)
Запрос проходит авторизацию и лимиты, получает уникальный код, затем атомарно сохраняется в нужном шарде. Глобальная блокировка всех создаваемых ссылок не нужна и станет узким местом.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Условие
В рамках полной архитектуры сервиса присутствуют:
- API‑шлюз с балансировкой нагрузки и проверкой прав доступа
- Сервис TinyUrl, отвечающий за POST‑запросы
- Внешний генератор коротких URL (Tiny URL creator)
- Распределённый реальный замок (real lock)
- Кеш‑слой (LRU)
- Горизонтально масштабируемая SQL‑БД с репликацией
Требуется описать и спроектировать весь путь создания короткой ссылки:
- Как запрос от клиента проходит через API‑шлюз
- Как формируется short_link с учётом блокировки (учитывая 200 млн ссылок + real lock)
- Как запись попадает в соответствующий шард SQL‑БД
- Нужно ли обновлять кеш и как это делается
- Какие узкие места могут возникнуть и какие стратегии масштабирования применимы
Ответ
Запрос проходит авторизацию и лимиты, получает уникальный код, затем атомарно сохраняется в нужном шарде. Глобальная блокировка всех создаваемых ссылок не нужна и станет узким местом.
Используйте idempotency key для повторов POST, генератор с независимыми диапазонами или случайные коды с проверкой UNIQUE. Маршрутизация по коду должна однозначно определять шард, иначе локальный UNIQUE не даст глобальной уникальности. Если real lock обязателен, ограничьте его конкретным ключом и учитывайте истечение lease. Кэш заполняйте только после commit, с TTL не дольше жизни ссылки. Для read-after-write учитывайте задержку реплики. Масштабируйте генерацию, шарды и локальные кэши; 200 млн записей сами по себе не задают QPS.