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