100 млн запросов за 30 дней — примерно 39 RPS в среднем. Нужны пиковая нагрузка и точное определение ≤1 мс: такой end-to-end SLA через интернет нереалистичен.
Проектирование масштабируемого сервиса сокращения URL
100 млн запросов за 30 дней — примерно 39 RPS в среднем. Нужны пиковая нагрузка и точное определение ≤1 мс: такой end-to-end SLA через интернет нереалистичен.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Условие
Разработать сервис для сокращения ссылок, рассчитанный на высокую нагрузку. Нефункциональные требования:
- 100 млн запросов в месяц
- Пропорция чтений к записям 100 : 1
- Время отклика GET‑запроса ≤ 1 мс
- Срок жизни сокращённой ссылки — 1 год
- Обеспечение высокой доступности
- Возможность горизонтального масштабирования
Ответ
100 млн запросов за 30 дней — примерно 39 RPS в среднем. Нужны пиковая нагрузка и точное определение ≤1 мс: такой end-to-end SLA через интернет нереалистичен.
При соотношении чтений и записей 100:1 получается около миллиона новых ссылок в месяц и порядка 12 млн активных ссылок за год при равномерной нагрузке. Средний RPS сам по себе не требует сложного шардирования.
Базовая схема: несколько stateless API, реплицируемая БД с UNIQUE(short_code), кеш горячих ссылок и очередь аналитики. expires_at проверяют на чтении и чистят фоново; кеш не продлевает срок жизни. Для низкой задержки чтение обслуживают близко к пользователю, но отдельно измеряют серверный p99 и сетевую задержку. Пиковые коэффициенты, размер URL, consistency и правила failover нужно согласовать до выбора числа шардов.