Интервью по System Design. Александр Поломодов (Тинькофф) 

Крутяк, очень интересный пример! Спасибо большое!

1. Нет необходимости разносить booking DB - так нужно настраивать сложную синхронизацию между базами на бронь и на просмотр. immediate consistency страдает люди могут видеть дотсупным то, что уже забронировано. 2. Непонятно зачем при максимально прогнозируемой нагрузке в 1000 rps, которая и так превышает расчётную в 2 rps на 3 порядка, шардировать базу. Просто продемонстрировать, что можем? В общем много решений кажутся необоснованными и сильно усложнёнными, которые рассчитаны под гораздо более высокие нагрузки, но с кучей проблемных мест.

Интересное интервью, спасибо

Маркул затащил, спасибо за интервью

Забыли покрыть вопрос про то, как определяется, сколько доступных номеров будет на определенные даты. Здесь можно было бы и придраться к тому, что шардирование было выбрано неверно, с помощью consistent hashing, когда здесь скорее нужно было шардирование реализовывать через partitioning, на основе start_date. Таким образом нам не надо было бы ходить по всем шардам и искать пересечения по датам.

Собеседование оказалось проще, чем я представлял. Для человека, который хотя бы пару раз что-то проектировал и реализовывал самостоятельно должно быть не сложно. Просто мысли вслух о предметной области, ее моделях, подводных камнях и ожидаемых нагрузках. Я ожидал, что будет сильный уклон в тонкости работы отдельных компонентов системы: балансировки, меседжинга, масштабирования, репликации с синхронизацией в тонкостях, шардировании, кэшировании, проксирования и тд и тп.

Важнейший момент с поиском номеров пропустил, ну и аргументация в стиле тут можно MySQL , но особого смысла не вижу, пусть будет монго просто топчик)

Для тех кто не понял про date в таблице room_types. На 204 странице во второй книге System Design by Alex Xu это описано с примерам. Важная особенность, таблица room_types ПРЕДЗАПОЛНЕНА на пару лет вперед для всех дат.

Отличное интервью! Какие книги посоветуете почитать, чтобы подготовиться к подобному собеседованию? Спасибо

Очень полезный материал. Оба участника интервью потрясающе компетентны. Ловлю себя на мысли, что только теоретической подготовкой без реального практического опыта в проектировании подобных систем будет крайне сложно вытащить такой собес на достойном уровне.

А простите это разве c4?, тут прям какой то микс, очень смахивает на читерство(ну тее интервьюируемый явно знает что от него спрашивать будут)

К середине видео начинает парить, что кандидат вообще не дает говорить интервьюверу

Топ видос!

С первых секунд ощущение, что собеседуемый прекрасно знает, о чем он собирается рассказывать. Курсы Блиновской, короче.

Человек явный инженер, а не архитектор. Полез зачем-то сразу в детали, вместо нормальной постепенной декомпозиции.

Спасибо! Было очень интересно! 👍 Есть вопрос по корректности спроектированной модели данных для ответа на вопрос о возможности бронирования. Таблица room_types хранит количество бронирований для типа номеров. Запросы к ней позволят лишь ответить на вопрос о наличии типа номеров для периода времени, но при этом запросто может не оказаться ни одного конкретного номера для всего данного периода. Например, есть два номера одного типа. Один доступен лишь на 1 декабря, второй только на 2 декабря. Запрос о возможности бронирования на 1 и 2 декабря по таблице room_types ответит положительно, хотя на весь этот период ни первый, ни второй номер недоступны. Похоже, что решение о возможности оставаться в терминах только типа номеров, не опускаясь до конкретных номеров, неверное.

Hotels & rooms и booking часть тут на самом деле имеют довольно неявные границы и разделять я бы их не стал. Крайне редко кто-то будет запрашивать свободные комнаты исключительно по одному отелю, скорее всего, будет запрошен список комнат по нескольким отелям (по фильтрам). Что уже потребует склеивать данные и из базы отелей и из базы свободных room_type.

Мне кажется интервью в форме монолога прошло, было мало вопросов к бизнесу - а что собственно хотите, да и бизнес мало хотелок хотел, не менял требования каждые 5 минут p.s. на room_types мне кажется не стоит так фокусироваться - так как куда важней вид из окна, завтраки - куча других параметров фильтрации p.s. спасибо за интервью

Спасибо за такой интересный материал! А не лучше ли было бы не хранить room_types? вычислять свободные места с помощью запроса к reservation. При бронировании лочить hotel_id+room_type_id.

Room Types и статус booked нужно разделить

😂 ржал как конь полтора часа, пойду деньги выведу, а то мало ли …

Я тут не смог в сложную задачку про распределённые в сети транзакции при собесе в Тинькофф, которую проводил Игорь, поэтому напишу что забыли учесть тут)) Тут при пиковой нагрузке (условные >5000 RPS при просмотре страницы отеля из-за большого кол-ва изображений) на сеть упадёт нагрузка в 320 Gbit/s (одну картинку считаю как 1 мб). Даже облачный Amazon S3 вывозит максимум 100 Gbit/s, поэтому тут отдельная задача для многоуровневого шардирования S3 в собственном DC, мб даже на уровне DNS или организация крутой CDN P.S. знаком с ленивой подгрузкой, но тогда надо и про неё было сказать)) P.S.S. ах да, распределённая транзакция на оплате букинга! Это та же самая сага, на которой я погорел на собесе, срочно предлагаю обсудить её в комментариях!)

Наконец-то сильное system design на просторах рунета не по избитой теме из книги System design Alex Xu! Спасибо!

Надо сначала разбираться с бизнесом, данными и отношениями, потом рисовать архитектуру, даже контекст в C4 не стоит делать, пока не разберешься. Можно хоть логическую модель данных для начала составить, user story накидать, потом уже разбираться далее. Сразу системы накидывает итп, проектирование снизу, ну так себе... Потом в конце выяснится, что он не правильно понял отношения или не выяснил - и все переделывай :)

даже без приблизительного расчета производительности БД/количества запросов к ней - рассуждать о дэдлоках - это кринж какой

Спасибо, было интересно посмотреть. Но есть один важный момент: все принятые архитектурные решения не были обоснованы в принципе никак. Зачем и что он делает - понятно. Но вот вопрос почему? В данный момент сложилось ощущение, что человек, которого собеседуют, просто попытался всунуть все известные ему паттерны в одну диаграмму. С4 здесь не использовано. API First тоже, возможно, не лучший вариант.

Имхо тут с точки зрения базовой архитектуры запросов допущена ошибка. На сторону клиента румтайпы попадают уже в виде пакета предложений на группу участников, где пакет это комбинация каких-то румтайпов с распределением гостей. Вот он же сам привёл пример "хочу забронировать гостиницу для N сотрудников и дать им всем одноместные номера" и если в гостинице есть только ограниченное количество эконом номеров, но есть чуть подороже какой-нибудь условный economflex, то по его условиям бронирование свалится. Задача комбинирования комнат в пакеты должна решаться на бэке, а клиент должен только отдать запрос типа 2 человека в одной комнате, 2 взрослых плюс ребёнок в ещё одной и т.д.

1:14:03 всё еще жду этот sql запрос

Я не очень понял: кандидат прошел интервью или нет? Судя по тому, что он сразу начал рисовать схему, не задавая вопросы, он провалил собес.

Больше похоже на рассказ, не на интервью

Ну такое себе, есть как спорные моменты так просто ошибочные суждения, например, в начале, достаточно было указать что есть такие-то эндпоинты для получения/передачи информации с бекенда, какой смысл говрить об архитектуре REST и тем более давать сигнатуру эндпоинтов, которую разработчики всеравно не будут использовать по той причине что она кривая, поэтому нет никакого смысла в подсчетах рпс и филосовских рассуждениях о нагрузке, ведь все это разобьется о реальность в которой банально отсутствует пагинация)))

а я не понял как происходит бронирование если у него кол-во свободных лежат в одной бд, а резервейшен в другой бд, как он синхронизирует?

немного не рассказано про процесс показа свободных номеров. пользователь заходит вводит город или отель и хочет посмотреть список доступных номеров. По идее у нас есть отель, есть список комнат в этом отеле. Если допустим мы сразу этот номер не выдаем, тогда нам нужно, количество номеров в отеле по каждом типу, ну пускай это будет табличка рум тайп как указано на 44 минуте пока дальше не посмотрел. Ну хорошо менеджер добавил тогда в рум тайп добавилась запись с количеством номеров, ну пускай, при бронировании будем отминусовывать комнату определенного типа, ну пускай, но как происходит процесс выдачи свободных номеров по дате до сих пор не понятно. Допустим мы обращаемся к этой табличке и смотрим все доступные по городу и дате, и потом по айди отеля выводим информацию об отеле) ну возможно, но меня смущает, что до сих пор я этого не услышал

забавно, на яндекс собесе решил в таком же духе рассказать, руководитель интервьюер начал рисовать петлю с виселицей)

Данил прям вопрос задать не даёт 😅

можно задать любой вопрос, он в любом случае будет хорошим

anydoby knows the diagramming tool they're using?

Ребят, кто поопытнее подскажите. Даниил сказал, что для того чтобы не делать кросс запросы между сервисами и их базами, сделаем MQ и будем через неё формировать таблицу с каунтерами типов комнат. Но ведь очередь - это ассинхронизация. По идее может получиться так, что в момент букинга за MQ будет недосинхронизированная таблица и букинг проведет оплату, а на самом деле комнат свободных не было. Я не прав?

А кто кого собеседует?

у них там база на 20 000 отелей ~ ну пускай 20 ГБ - они ее шардировать хотят , еще и с consistent hashing и virtual shards ну клоуны

было скучно, полезнее сразу коменты прочитать

Часто пользуюсь отелями и слово овербукинг вызывает аллергию.. При овербукинге люди не могут заселиться и их отправляют ночевать в подвалы.. Подскажите, что здесь имелось в виду под требованием обеспечить овербукинг..? :-)

Ну кстати вот Данил как раз и жахнул у себя на схеме dual write с записью в БД и отправкой сообщения в очередь. Что-то я не помню вопроса от интервьюера как он вообще собирался это разруливать.

аппроксимация RPS бронирования на RPS от всех действий пользователей некорректная. Нельзя просто так 50 RPS переводить в 5 000 RPS, так как когда идет бронирование, то один пользователь действительно создает 1 запрос на ручку создания брони за сессию, так как он бронирует только один раз, а вот когда мы смотрим на все действия пользователей, то 1 человек создает >1 HTTP запроса за сессию. Таким образом определение потолка RPS некорректная в целом)

Что за дурацкая идея добавлять в кэш записи при создании новых сущностей отелей/комнат?

Универсальный принцип - отделять изменяемое от неизменяемого. Тут даже спорить неочем! Такое позволительно только джуну, который только после университета и толком не писал кода. Ибо такие вещи приходят на ум даже не читав книжки - это становится очевидным.

Муть. Позвали бы человека, который строил подобные системы.

Не понимаю, зачем выходить за рамки ФТ и расписывать то, о чем тебя не просят. Если накидать сверху юзкейсов от себя, что можно сутки только о них говорить. Зачем отдельная база Payment DB? Упомянался паттерн transactional outbox - это как раз о том, чтобы когда Booking API создавало букирование в Booking DB, то в рамках той же транзакции создавалась запись (задание) на отправку сообщения в Payment Service. Иначе теряется весь смысл этого паттерна и транзакционность.

Ппц, мне поставили интервью по системдизайну, а я никогда таким не занимался, практического опыта нету. Смотрю материалы, вижу что всё далеко не просто. Такое ощущение что я обязательно накосячу и меня попросят нафиг. 😥

Странно почему пользователь может входить в Hotel&Rooms sys и тут же в Booking System, мне кажется это не верно! Для пользователя должна быть 1 точка входа (фронт, которой ходит на Hotel&Rooms и он уже, в Booking System)

19

В таблце резервации не должно быть статуса. Это нужно хранить в отдельной таблице многие к одному - в качестве event sourcing

подобные интервью - зло. я вообще категорически против таких интервью без предварительно согласованных 1) теребований 2) глоссария 3) пунктов оценивания (а в идеале ещё бы и согласованное оценивание в присутствии кандидата), потому что в итоге получается, что кандидата недослушали или он додумал какие-то требования интуитивно и забыл это проговорить и ещё куча и куча всякого субъективизма, который в итоге приводит к недооценённости кандидата. гораздо лучше просто поговорить про какие-то отдельные подходы или попросить рассказать про опыт и позадавать вопросы, так человек раскроется гораздо лучше и не будет биаса относительно кривых требований к тестовой архитектуре.

Не могу понять почему люди это называют System Design. Это не System Design. Это System Design of Web services

очень душный, не умеет слушать интервьюера

Неужели так сложно сделать выравнивание громкость спикеров ? PS: Кринж быть программистом и не купить норм микрофон

она даже не спросил сколько пользователей какие цели у бизнеса ни какие самые критические функции. человек перемазывает решение, которое где то видел...

молрдеж прям хотят на уровень запросов спуститься, на уровнь вью. эта хня типовая и так всем известна, тут про архитектуру сверху, звучит тупо для мидлов, но наверху многие вещи очевидны и типовые, потому не проговариваются

Детский сад. Весь ютуб завален какими-то взрослыми мужиками, играющими в бесконечный "API gateway" и составляющими диаграммы БД-табличек. Идите опердень свой делать в каком-нибудь мерзком "Тинькове" уже.