Интервью по System Design. Александр Поломодов (Тинькофф)
HTML-код
- Опубликовано: 17 ноя 2022
- Выступление на конференции ArchDays 2022 archconf.ru/arch
Архитектурное собеседование - одно из самых сложных как для кандидата, так и для интервьюера. Оно достаточно часто встречается в зарубежной практике и иногда в российских компаниях. Мы устроили System Design Interview в realtime с флипчартом и посмотрели, как обычно проходит интервью, какие знания и навыки нужны кандидату, и заодно разобрали ошибки, которые могут допустить обе стороны.
1. Нет необходимости разносить booking DB - так нужно настраивать сложную синхронизацию между базами на бронь и на просмотр. immediate consistency страдает люди могут видеть дотсупным то, что уже забронировано.
2. Непонятно зачем при максимально прогнозируемой нагрузке в 1000 rps, которая и так превышает расчётную в 2 rps на 3 порядка, шардировать базу. Просто продемонстрировать, что можем?
В общем много решений кажутся необоснованными и сильно усложнёнными, которые рассчитаны под гораздо более высокие нагрузки, но с кучей проблемных мест.
Крутяк, очень интересный пример! Спасибо большое!
Интересное интервью, спасибо
К середине видео начинает парить, что кандидат вообще не дает говорить интервьюверу
Отличное интервью! Какие книги посоветуете почитать, чтобы подготовиться к подобному собеседованию? Спасибо
Для тех кто не понял про date в таблице room_types. На 204 странице во второй книге System Design by Alex Xu это описано с примерам. Важная особенность, таблица room_types ПРЕДЗАПОЛНЕНА на пару лет вперед для всех дат.
Не ясно почему roomtype является событием если из название выходит что это тип комнаты
это ваще не очевидно, если учесть название таблицы.
Важнейший момент с поиском номеров пропустил, ну и аргументация в стиле тут можно MySQL , но особого смысла не вижу, пусть будет монго просто топчик)
Маркул затащил, спасибо за интервью
Очень полезный материал. Оба участника интервью потрясающе компетентны. Ловлю себя на мысли, что только теоретической подготовкой без реального практического опыта в проектировании подобных систем будет крайне сложно вытащить такой собес на достойном уровне.
А в реальное проектирование не попасть без такого собеса, рекурсия однако )
@@anideth почему же? вы можете работая на текущем месте поспрашивать у коллег, как устроена система, почему она такая и тп. параллельно почитать о проектировании. и в конечном итоге у вас уже будет не плохая теротическая база, а сд интервью обычно идет третьим этапом, там уже больше смотрят как раз на кругозор и оценку ваших компетенций. если все сойдется и в конечном итоге у вас будет желание развиваться в архитектора, то вам помогут и дополнят ваши знания практикой)
Забыли покрыть вопрос про то, как определяется, сколько доступных номеров будет на определенные даты. Здесь можно было бы и придраться к тому, что шардирование было выбрано неверно, с помощью consistent hashing, когда здесь скорее нужно было шардирование реализовывать через partitioning, на основе start_date. Таким образом нам не надо было бы ходить по всем шардам и искать пересечения по датам.
А простите это разве c4?, тут прям какой то микс, очень смахивает на читерство(ну тее интервьюируемый явно знает что от него спрашивать будут)
С первых секунд ощущение, что собеседуемый прекрасно знает, о чем он собирается рассказывать. Курсы Блиновской, короче.
Скорее всего такое ощущение складывается из-за того, что все мы, блин, пользовались хотя бы раз известными сервисами бронирования.
Мне тоже так показалось. Слишком бодро и быстро набрасывает, вообще не думая. Интересно, кто-то ведет статистику, сколько людей вообще укладывают это интервью в 1 час времени?
Ну тему заранее сообщили и он неделю готовился 😊
Я не очень понял: кандидат прошел интервью или нет? Судя по тому, что он сразу начал рисовать схему, не задавая вопросы, он провалил собес.
Александр ответил, что прошёл на уровень senior.
Прошел конечно - он же свой. Но новые клоны Дани не пройдут ибо много недочетов - по паутинке оценки Саши он еле еле до норм дотягивает - дали бы отлуп - вы недостаточно хороши)))
Спасибо за такой интересный материал! А не лучше ли было бы не хранить room_types? вычислять свободные места с помощью запроса к reservation. При бронировании лочить hotel_id+room_type_id.
По идее если система работает как aviasales условный - т.е. юзер запрашивает: "покажи мне, где свободные места в отелях с 19.05 по 25.06 в Красноярске", то вычислять можно, но это будет очень долго. Вычисления же не по одному отелю пойдут, а по нескольким и по нескольким датам. А учитывая, что бронирует 1% из просматривающих и уже это дает 50 RPS в пике - просто запросы свободных мест могут давать до 5000 RPS, что просто положит базу со всеми этими вычислениями.
@@user-os7kg2me6g сорян, но в Красноярске нет столько отелей, чтобы положить такими несложными вычислениями что-либо) А насчет 5к рпс - это 18 миллионов пользователей в час) То есть чуть ли не 15% населения страны должны ломануться одновременно порыскать поискать отели что ли) Бронирование не ситуативно, люди планируют отпуск месяцами.
даже без приблизительного расчета производительности БД/количества запросов к ней - рассуждать о дэдлоках - это кринж какой
Спасибо! Было очень интересно! 👍 Есть вопрос по корректности спроектированной модели данных для ответа на вопрос о возможности бронирования. Таблица room_types хранит количество бронирований для типа номеров. Запросы к ней позволят лишь ответить на вопрос о наличии типа номеров для периода времени, но при этом запросто может не оказаться ни одного конкретного номера для всего данного периода. Например, есть два номера одного типа. Один доступен лишь на 1 декабря, второй только на 2 декабря. Запрос о возможности бронирования на 1 и 2 декабря по таблице room_types ответит положительно, хотя на весь этот период ни первый, ни второй номер недоступны. Похоже, что решение о возможности оставаться в терминах только типа номеров, не опускаясь до конкретных номеров, неверное.
Аналогичный вопрос возник при просмотре, система совершенно не даёт ответа сколько комнат на свободные даты
Вообще, отели могут такие кейсы хавать, переселяя из одного номера в другой, тут зависит от требований бизнеса
да, по бырому люди тупят, час же. архитектура это вопрос недель так то, не?
В задаче обозначено что поиск и фильтрация за скоупом рассмотрения находятся, считается что этот вопрос уже решен
@@user-cz7xo7uq4y тогда за скопом и модель бд.
а я не понял как происходит бронирование если у него кол-во свободных лежат в одной бд, а резервейшен в другой бд, как он синхронизирует?
Выше отметили что паттерн Сага надо юзать.
Через паттерны распределённых транзакций (сага, 2pc, аутбокс). Вообще не очень понятно, зачем здесь юзать разные бд, если для логики бронирования можно оставить одну
@@buginsystem8925 чтобы юзать паттерны, больше не для чего...
Ну это обычно так и есть. В жизни эти два потока данных сильно разделены и синхронизируются совсем не в момент резервирования, а много позже и уж совсем не по базе. Это стандарт в системах бронирования и человек, очевидно, это знал.
Человек явный инженер, а не архитектор. Полез зачем-то сразу в детали, вместо нормальной постепенной декомпозиции.
так это интервью для инженеров, а не архитекторов..
@@endyrocketstarбуквально интервью по системной архитектуре…
@@buginsystem8925 инженерам не нужно знать системную архитектуру?
Мне кажется интервью в форме монолога прошло, было мало вопросов к бизнесу - а что собственно хотите, да и бизнес мало хотелок хотел, не менял требования каждые 5 минут
p.s. на room_types мне кажется не стоит так фокусироваться - так как куда важней вид из окна, завтраки - куча других параметров фильтрации
p.s. спасибо за интервью
Ну кандидат же должен быть проактивным. Далее Александр ответил, что кандидат уточнял. Ты считаешь, что недостаточно?
Спасибо, было интересно посмотреть. Но есть один важный момент: все принятые архитектурные решения не были обоснованы в принципе никак. Зачем и что он делает - понятно. Но вот вопрос почему? В данный момент сложилось ощущение, что человек, которого собеседуют, просто попытался всунуть все известные ему паттерны в одну диаграмму. С4 здесь не использовано. API First тоже, возможно, не лучший вариант.
А как ты считаешь надо обосновывать?
Чёт абсолютно аналогичное мнение сложилось, хотя я миддл. Зачем разделять тесно связанный бизнес-требованиями функционал на разные сервисы с разными бд и запариваться с распределёнными транзакциями, зачем шарды и мастер-слейвы при 5к рпс, почему везде именно тот, а не иной паттерн… При этом интерьюер спрашивает, как будут реализованы основные бизнес-требования, просто изложенные в самом начале, и ответ на каждый вопрос либо не предусмотрен в такой системе, либо выглядит сильно неоптимальным (именно из-за лишней усложнённости).
Понятно, что на интервью можно продемонстрировать свои знания, но тут будто не демонстрация знаний, а одно "ДА, ДА, Я СЛЫШАЛ ОБ ЭТОЙ ТЕХНОЛОГИИ, ВИДИТЕ".
Room Types и статус booked нужно разделить
Я тут не смог в сложную задачку про распределённые в сети транзакции при собесе в Тинькофф, которую проводил Игорь, поэтому напишу что забыли учесть тут))
Тут при пиковой нагрузке (условные >5000 RPS при просмотре страницы отеля из-за большого кол-ва изображений) на сеть упадёт нагрузка в 320 Gbit/s (одну картинку считаю как 1 мб). Даже облачный Amazon S3 вывозит максимум 100 Gbit/s, поэтому тут отдельная задача для многоуровневого шардирования S3 в собственном DC, мб даже на уровне DNS или организация крутой CDN
P.S. знаком с ленивой подгрузкой, но тогда надо и про неё было сказать))
P.S.S. ах да, распределённая транзакция на оплате букинга! Это та же самая сага, на которой я погорел на собесе, срочно предлагаю обсудить её в комментариях!)
Про сагу норм отметил. Зачем многоуровневое S3? Сам же про CDN отметил.
Ты на собесе уточнял по нагрузкам? Будут ли картинки? Если, к примеру, не было в изначальном условие, то, может, и не надо об этом? Или именно про них и спросили? Если спросили то, наверное, уже как доп вопрос, а не в основном разборе? Тогда ты основной, получается, нормально прошёл. Хотя, ты сказал, что не прошёл. Странно это всё))
Поясни, плиз)
40 гигабит/с
Александр отметил, что нужен был бы cdn в своих комментариях сразу после интервью. А по вопросу распределенной транзакции при оплате Даниил упомянул, что потребуется transactional outbox (назвав его мэил аутбокс что ли)
Наконец-то сильное system design на просторах рунета не по избитой теме из книги System design Alex Xu! Спасибо!
Да вроде как раз это полный пересказ главы из второй части System design by Alex Xu)
@@nikscorp ребят а как эта книга вообще, стоит внимания? Или уже не актуальна?
@@Levelord92 мне показалось весьма полезной именно для подготовки к собеседованиям, особенно если уже есть бэкграунд в распределённых системах. Там именно про то как эти собесы предлагается проходить и разборы самых частых типовых вопросов.
Часто рекомендуют курс на educative, он очень сильно с ней пересекается.
Но надо понимать, что книжка и курс местами поверхностные, где-то решения предлагаются сомнительные, где-то deep dive недостаточно deep. В идеале кмк еще прочитать Клепмана и поразбирать решения вопросов из книжки с друзьями.
Но это все чисто имхо.
@@nikscorp охренеть, просто охренеть сколько всего нужно, чтобы просто пройти собеседование по систем дизайну) В реальности будь ты хоть сеньор, ты не архитектор - никто не даст тебе волю скалировать сервера, подключать CDN и прочее. И даже после этого доклада искренне не понимаю для чего об этом спрашивают миддлов, так как участие в таких решениях они всё равно не принимают.
P.S. я не так давно натыкался на какой-то сайтец по систем дизайну, где помимо теории разобраны в том числе всякие инстаграммы и твиттеры, но не могу найти. Пол-дня в истории браузера сегодня рылся.
Книжка опасная для новичка, структура изложения да, ОК, но когда автор токен в get запрос вставляет - такую книгу можно выбросить и таких мелких косяков масса.
Hotels & rooms и booking часть тут на самом деле имеют довольно неявные границы и разделять я бы их не стал. Крайне редко кто-то будет запрашивать свободные комнаты исключительно по одному отелю, скорее всего, будет запрошен список комнат по нескольким отелям (по фильтрам). Что уже потребует склеивать данные и из базы отелей и из базы свободных room_type.
Мне кажется, реальный букинг так и работает - ты выбираешь дату, тип номера и иногда диапазон цены, и тебе кучу номеров в разных отелях выдаёт.
Надо сначала разбираться с бизнесом, данными и отношениями, потом рисовать архитектуру, даже контекст в C4 не стоит делать, пока не разберешься. Можно хоть логическую модель данных для начала составить, user story накидать, потом уже разбираться далее. Сразу системы накидывает итп, проектирование снизу, ну так себе... Потом в конце выяснится, что он не правильно понял отношения или не выяснил - и все переделывай :)
anydoby knows the diagramming tool they're using?
Miro
😂 ржал как конь полтора часа, пойду деньги выведу, а то мало ли …
Что смешного?
Больше похоже на рассказ, не на интервью
Топ видос!
Часто пользуюсь отелями и слово овербукинг вызывает аллергию.. При овербукинге люди не могут заселиться и их отправляют ночевать в подвалы.. Подскажите, что здесь имелось в виду под требованием обеспечить овербукинг..? :-)
Ну имелось в виду бизнес-требование отправить людей в подвалы, чево непонятно.
Овербукинг-это не про подвалы. 99% овербукинга разразрешается совершенно незаметно для клиента. Без овербукинга цены были бы намного больше.
Что за дурацкая идея добавлять в кэш записи при создании новых сущностей отелей/комнат?
А кто кого собеседует?
Имхо тут с точки зрения базовой архитектуры запросов допущена ошибка. На сторону клиента румтайпы попадают уже в виде пакета предложений на группу участников, где пакет это комбинация каких-то румтайпов с распределением гостей. Вот он же сам привёл пример "хочу забронировать гостиницу для N сотрудников и дать им всем одноместные номера" и если в гостинице есть только ограниченное количество эконом номеров, но есть чуть подороже какой-нибудь условный economflex, то по его условиям бронирование свалится. Задача комбинирования комнат в пакеты должна решаться на бэке, а клиент должен только отдать запрос типа 2 человека в одной комнате, 2 взрослых плюс ребёнок в ещё одной и т.д.
Ребят, кто поопытнее подскажите. Даниил сказал, что для того чтобы не делать кросс запросы между сервисами и их базами, сделаем MQ и будем через неё формировать таблицу с каунтерами типов комнат. Но ведь очередь - это ассинхронизация. По идее может получиться так, что в момент букинга за MQ будет недосинхронизированная таблица и букинг проведет оплату, а на самом деле комнат свободных не было. Я не прав?
я думаю переходя вглубь воронки бронирования, тебе выскачет окошко, что сорян, номер уже недоступен
@@zhukov1337 Или свалится в овербукинг, что вообщем не страшно.
1:14:03 всё еще жду этот sql запрос
А сам как бы написал?)
немного не рассказано про процесс показа свободных номеров. пользователь заходит вводит город или отель и хочет посмотреть список доступных номеров. По идее у нас есть отель, есть список комнат в этом отеле. Если допустим мы сразу этот номер не выдаем, тогда нам нужно, количество номеров в отеле по каждом типу, ну пускай это будет табличка рум тайп как указано на 44 минуте пока дальше не посмотрел. Ну хорошо менеджер добавил тогда в рум тайп добавилась запись с количеством номеров, ну пускай, при бронировании будем отминусовывать комнату определенного типа, ну пускай, но как происходит процесс выдачи свободных номеров по дате до сих пор не понятно. Допустим мы обращаемся к этой табличке и смотрим все доступные по городу и дате, и потом по айди отеля выводим информацию об отеле) ну возможно, но меня смущает, что до сих пор я этого не услышал
Сейчас понял?
Ну кстати вот Данил как раз и жахнул у себя на схеме dual write с записью в БД и отправкой сообщения в очередь. Что-то я не помню вопроса от интервьюера как он вообще собирался это разруливать.
А че там разруливать, сохраняешь и кидаешь в аутбокс
@@ferm3r а в аутбоксе что происходит?
@@Sousleek Чтение воркером и отправка в MQ
@@vlnd0 а в воркере будет написана отправка сообщения из базы в в очередь + простановка в базе атрибута о том что успешно отправлено сообщение? Это тоже dual write :)
@@Sousleek а чем это плохо?
забавно, на яндекс собесе решил в таком же духе рассказать, руководитель интервьюер начал рисовать петлю с виселицей)
Ну такое себе, есть как спорные моменты так просто ошибочные суждения, например, в начале, достаточно было указать что есть такие-то эндпоинты для получения/передачи информации с бекенда, какой смысл говрить об архитектуре REST и тем более давать сигнатуру эндпоинтов, которую разработчики всеравно не будут использовать по той причине что она кривая, поэтому нет никакого смысла в подсчетах рпс и филосовских рассуждениях о нагрузке, ведь все это разобьется о реальность в которой банально отсутствует пагинация)))
Не понимаю, зачем выходить за рамки ФТ и расписывать то, о чем тебя не просят. Если накидать сверху юзкейсов от себя, что можно сутки только о них говорить.
Зачем отдельная база Payment DB? Упомянался паттерн transactional outbox - это как раз о том, чтобы когда Booking API создавало букирование в Booking DB, то в рамках той же транзакции создавалась запись (задание) на отправку сообщения в Payment Service. Иначе теряется весь смысл этого паттерна и транзакционность.
Данил прям вопрос задать не даёт 😅
аппроксимация RPS бронирования на RPS от всех действий пользователей некорректная. Нельзя просто так 50 RPS переводить в 5 000 RPS, так как когда идет бронирование, то один пользователь действительно создает 1 запрос на ручку создания брони за сессию, так как он бронирует только один раз, а вот когда мы смотрим на все действия пользователей, то 1 человек создает >1 HTTP запроса за сессию. Таким образом определение потолка RPS некорректная в целом)
надо реальные статы брать, но вобще у тебя гранулярность проектирования по мощностям большая, тут порядки +- неважно
Странно почему пользователь может входить в Hotel&Rooms sys и тут же в Booking System, мне кажется это не верно!
Для пользователя должна быть 1 точка входа (фронт, которой ходит на Hotel&Rooms и он уже, в Booking System)
Он позже нарисовал Api gateway.
Универсальный принцип - отделять изменяемое от неизменяемого. Тут даже спорить неочем!
Такое позволительно только джуну, который только после университета и толком не писал кода. Ибо такие вещи приходят на ум даже не читав книжки - это становится очевидным.
Ппц, мне поставили интервью по системдизайну, а я никогда таким не занимался, практического опыта нету. Смотрю материалы, вижу что всё далеко не просто. Такое ощущение что я обязательно накосячу и меня попросят нафиг.
😥
И как в итоге прошло?)
@@pro_ussr В итоге прослушал еще пару таких видео с семпловым интервью + нарисовал схемы для полутора семпловых задач. Конкретный результат назначенного интервью мне не сказали, но я его прошел. Претендовал на "middle+".
@@onewhoraisesvoice молодец! Какой язык, должность?
@@vova_dev Python, data engineer.
В таблце резервации не должно быть статуса. Это нужно хранить в отдельной таблице многие к одному - в качестве event sourcing
было скучно, полезнее сразу коменты прочитать
Муть. Позвали бы человека, который строил подобные системы.
у них там база на 20 000 отелей ~ ну пускай 20 ГБ - они ее шардировать хотят , еще и с consistent hashing и virtual shards
ну клоуны
ты клоун) какой размер шарда в шардированной базе должен быть по-твоему?
@@waagnermann а по твоему какой?:)))
@@waagnermann ну монга до терабайта не умирает. вопрос зачем лишние человека-часы на разработку и поддержку этой бадьи брать. вообщем вред для бизнеса
Эту тему они стали развивать когда речь зашла о расширении сервиса по миру
очень душный, не умеет слушать интервьюера
С английским у архитектора беда
@@widgetiiда и с русским.
Я бы даже сказал, что перебивает
Не могу понять почему люди это называют System Design. Это не System Design. Это System Design of Web services
19
Неужели так сложно сделать выравнивание громкость спикеров ?
PS: Кринж быть программистом и не купить норм микрофон
она даже не спросил сколько пользователей какие цели у бизнеса ни какие самые критические функции. человек перемазывает решение, которое где то видел...
молрдеж прям хотят на уровень запросов спуститься, на уровнь вью. эта хня типовая и так всем известна, тут про архитектуру сверху, звучит тупо для мидлов, но наверху многие вещи очевидны и типовые, потому не проговариваются
Детский сад. Весь ютуб завален какими-то взрослыми мужиками, играющими в бесконечный "API gateway" и составляющими диаграммы БД-табличек. Идите опердень свой делать в каком-нибудь мерзком "Тинькове" уже.
дядь а где не детский сад? Покажи пжл
@@aksel58 конпуктер изучи сначала чтобы таблички не рисовать. Потом сам поймешь.
По существу будет что-то, или только высокомерный недоюмор?
@@aksel58 дай угадаю: ты же очень любишь аниме, да?
Видимо по существу не будет, очередной токсичный умник, которого не взяли (возможно в Тинькофф) из-за софт-скиллов