Подготовка к интервью по системному дизайну (System Design Interview)
Часть 4. Спроектируем сервис для сокращения URL на подобии TinyUrl.
Предыдущие статьи : Часть 1, Часть 2, Часть 3. Прежде чем читать эту статью, рекомендую прочитать предыдущие, в которых описываются основные этапы интервью по системному дизайну.
Давайте спроектируем сервис для сокращения URL. Этот сервис будет предоставлять короткие псевдонимы/ссылки, которые будут перенаправлять на полный URL .
Спроектируем сервис для сокращения URL на подобии TinyURL.
1. Почему нам необходимо сокращение URL?
Сокращение URL используется что бы создать короткий алиас для длинного URL. Мы назовем эти короткие алиасы “короткие ссылки”.
Пользователи перенаправляются на оригинальный URL, когда переходят по “короткой ссылке”. “Короткие ссылки” сохраняют много места, когда отображаются, печатаются, передаются или твитятся. Кроме того, пользователь с меньшей вероятностью ошибется набирая короткий URL.
Для примера:
Исходный URL : https://www.educative.io/collection/page/5668639101419520/56490502253445
После использования TinyUrl :
Короткие ссылки обычно занимают 1/3 от размера оригинального URL. Короткие ссылки используются для оптимизации передачи ссылок между устройствами, отслеживания индивидуальных ссылок, используется для анализа аудитории и эффективности компании, а так же скрытия уязвимых оригинальных URL адресов.
Если вы никогда не использовали TinyURL.com до этого, пожалуйста попробуйте создать новый короткий URL и проведите немного времени на сайте, используя различные настройки и опции, которые предоставляет сервис. Это поможет лучше понять эту главу.
2. Требования и цели системы
!!! Вы должны всегда прояснять требования в начале интервью.
Обязательно задавайте вопросы, чтобы выяснить точную область действия/применения системы, которую интервьюер имеет ввиду.
— Функциональные требования
1. На каждый URL наш сервис должен генерировать короткий и уникальный алиас называемый “короткой ссылкой”.
2. Когда пользователь использует короткую ссылку, наш сервис должен перенаправлять их на оригинальную ссылку.
3. У пользователей должна быть возможность , по желанию, выбрать свой алиас для короткого URL.
4. Ссылки истекают после стандартного промежутка времени. Пользователь должен иметь возможность указать срок действия ссылки.
— Не функциональные требования
1. Система должна быть высокодоступной. Это необходимо потому что если наш сервис упадет, то все перенаправления перестанут работать (начнут терпеть неудачу).
2. Редирект должен происходить в реальном времени с минимальными задержками.
3. Короткие ссылки не должны быть угадываемыми (предсказуемыми)
— Дополнительные/ расширенные требования
1. Аналитика. Как часто случается редирект?
2. Наш сервис должен быть доступен по REST API для других сервисов.
3. Расчет нагрузки и ограничений.
Наша система будет больше принимать запросов на чтение. Будет много запросов на перенаправление , по сравнению с созданием новых коротких ссылок. Давайте предположим что соотношение будет 100 к 1 между чтением записью.
Оценка трафика:
Если мы предположим что будем иметь 500 миллионов новых коротких ссылок в месяц , мы можем ожидать 50 миллиардов (100 * 500M = 50 Billlions) перенаправлений за тот же период. Какими будут запросы в секунду (QPS) для нашей системы?
Создание новых коротких ссылок в секунду:
500 million / (30 days * 24 hours * 3600 seconds) = ~200 URLs/s
Перенаправление в секунду, учитывая отношение 100:1 чтение/запись:
50 billion / (30 days * 24 hours * 3600 sec) = ~19K/s
Оценка хранилища:
Давайте предположим что мы храним каждый запрос на создание короткой ссылки (полную и короткую ссылку) в течении пяти лет. Так как мы ожидаем 500 миллионов новых URL каждый месяц,
общее количество объектов для сохранения составит 30 миллиардов:
500m * 5 years * 12 month = 30 billions
Предположим, что каждый сохраненный объект будет весить примерно 500 bytes (просто приблизительно — мы углубимся в это позже) .
Нам потребуется 15TB общего хранилища:
30 billion * 500 bytes = 15 TB
Оценка пропускной способности:
Для запросов на запись, с учетом 200 новых URL в секунду.
Суммарный входящий трафик для нашего сервиса будет равен 100KB в секунду:
200*500 bytes = 100KB/sec
Для запросов на чтение, так как мы ожидаем ~19K URLs перенаправлений,
всего исходящих данных для нашего сервиса будет 9MB в секунду:
19K * 500bytes = ~9MB/sec
