Mock-собеседование по System Design от Team Lead из Ozon
Вставка
- Опубліковано 28 чер 2024
- Потренироваться проходить собеседования: clck.ru/3ASssc
Курсы по программированию: clck.ru/3ASt6y
Mock-собеседование от Team Lead из Ozon секции по языку Golang на платформе it-interview.io. Потренируйтесь и вы проходить собеседования с разработчиками из ведущих компаний и получите подробный отзыв о том, на какую зарплату и грейд вы можете расчитывать, или над чем вам еще стоит поработать!
Telegram канал Олега: t.me/oo_ilin
UA-cam канал Олега: / @oo_ilin
Таймкоды:
00:00 Знакомство
03:31 Начинаем проектировать URL Shortner
04:02 Сбор функциональных требований
07:53 Сбор нефункциональных требований
12:56 Схема данных и рассчет объема базы
22:42 Рассчет RPS
23:53 Рассчет пропускной способности
26:30 Высокоуровневая схема
30:45 База данных
32:28 Шардирование базы данных
37:14 API
39:09 Шардирование продолжение
41:45 Добавляем кэш
45:03 Уникальность ключей на шардах
48:13 Внешний сервис для генерации ссылок
53:13 Соединяем потоки
53:56 Поток создания
58:24 Добавляем аналитику
1:00:25 Добавляем RateLimiter
1:04:16 Возвращаемся к аналитике
1:05:13 Обсуждаем точки отказа
1:09:06 Обсуждаем идемпотентность
1:14:12 Обратная связь от Олега
1:18:10 Обратная связь от Саши
[[ Отзыв о кандидате ]]
Александр во время собеседования показал себя хорошо. Показал себя как специалист способный анализировать предметную область и способный подстраиваться под новые требования. В качестве системы для проектирования был выбран URL Shortnet (сокращатель ссылок). Кандидат собрал все требования, реализовал верхнеуровневый дизайн и постепенно углубился до компонентов. Из плюсов еще могу отметить что разделил трафик на чтение и на запись и проработал оба потока данных. Проработал систему хранения, масштабирования и отказоустойчивости.
В ходе интерью из за того что сразу не спроектировал API ошибся с выбором ключа для шардирования данных. Но после того как спроектировал две API ручки быстро сообразил в какую сторону необходимо смотреть. Так же не до конца раскрыл как именно будет генерироваться уникальная ссылка. Не определились со словарем и полным алгоритмом.
По коммуникациям приятный в общении, рассудительный. Все предположения обосновывает и рассуждает в слух, что дает понять в какую сторону движется.
Из рекомендаций можно посоветовать следить за таймингом, чаще просматривать первоначальный требования и не повторяться на тех моментах, которые уже были овучены ранее.
#собеседование #mockсобеседование
неверно же посчитал пропускную способность
40 wRps x 300 байт = 12,000 байт/сек = 0.094 Мбит/сек
Что если упадет хранилище заготовленных ссылок 200кк ?
Если это inMemory хранилище, то при рестарте оно восполнится снова этими же заготовками или же будут новые заготовки ? 🤔
26 букв, + верхний регистр + числа в 8 символах это 62^8 возможных уникальных значений. разве вероятность коллизии высокая?
В вашем варианте словарь хороший и коллизий в принципе нет если генерировать ключ последовательно. Речь шла о другом. Что если взять какой-нибудь алгоритм хеширования, например MD5, то у него длина 32 символа, а сами символы это всего лишь шестнадцатиричная система: 0-9A-F. Так как наша задача сделать короткую ссылку, то если мы от md5 отрежим 8 символов, то будет очень высокая вероятность коллизии. Ну и в интервью я подталкивал Сашу на то что 8 символов это очень большое число уникальных значений и ключ можно сократить до 6 или 7 символов.
@@oo_ilinКажется для того, чтобы ответить на этот вопрос, стоило понять какие конкретно символы у нас есть (алфавит), допустим если алфавит 72 (26 uppercase/lowercase, 10 цифр и 10 спец символов), то нам нужно как раз таки 6 символов (log72(10^10), 10^10 - потому что у меня получилось 12 * 10^9 ссылок за 10 лет, что примерно равно 10^10). Ну и блочный CRC как раз таки идеально подходит под эту задачу. Вообще задача хоть и тривиальная на первый взгляд, но может проверить глубокие знания и даже умение считать
Почему тут не модет быть проблема селебрити? Кто-то популярный создал ссылку и разметил ее у себя в соц. сетях, на эту одну ссылку будет очень много запросов на чтение. Кажеться интервьюируемый правильно задал вопрос.
Потому что проблема селебрити в том что один человек может иметь много связей. Например много подписчиков и проблема оповестить всех о выходе нового поста. Тут ты делаешь ровно один адрес и никого не уведомляешь. Тут проблема высокого трафика, а это уже другая история.
А в чем вы схемки рисуете?
Excalidraw