Mock-собеседование по System Design от Team Lead из Ozon

Коротко о видео

В полном мок-собеседовании Олег и Александр проектируют URL Shortener: уточняют требования и нагрузку, строят хранилище и API, затем обсуждают шардирование, кэш, генерацию ключей, аналитику, rate limiting и отказоустойчивость. Интервьюер возвращает кандидата к API как основанию для выбора ключа шардирования и указывает на риск коллизий при усечении хэша. В финале интервьюер считает основные этапы пройденными, но рекомендует быстрее идти по плану и не повторять уже объяснённые решения.

Затронутые темы

Что взять на заметку

• Перед архитектурой зафиксируйте API и сценарии чтения: здесь GET получает длинную ссылку по short code без редиректа, а POST создаёт short code для long URL.
• Нагрузку важно не перепутать: условие — 100 млн новых ссылок в месяц и соотношение чтений к записям 100:1, то есть в среднем около 40 записей/с и около 4 000 чтений/с.
• Для 10 лет хранения при примерно 300 Б на запись порядок объёма составляет около 3,6 ТБ для 12 млрд ссылок; расчёт нужно перепроверять вместе с единицами измерения.
• Ключ шардирования должен следовать реальному маршруту чтения: искать будут по short code, поэтому шардирование по long URL не позволяет сразу найти нужный шард.
• При сильном перекосе в чтение имеет смысл разделить POST- и GET-сервисы за API Gateway, масштабировать GET отдельными репликами и поставить LRU/TTL-кэш между GET-сервисом и БД.
• Усечение хэша, например MD5, до восьми символов не гарантирует уникальность. В видео обсуждают пул заранее сгенерированных кодов с распределённой блокировкой и освобождением lease при сбое, но полный алгоритм генерации остаётся нераскрытым.
• Аналитику переходов можно учитывать только для успешных ответов и отправлять асинхронно через лог или очередь; rate limiting для создания ссылок размещают в Gateway, а при повторных POST-запросах отдельно уточняют семантику идемпотентности и допустимость нескольких short URL для одного long URL.