На мой взгляд систем дизайн это всегда разговор, как с коллегой, не всегда крайние случаи и острые углы архитектуры может продумать один человек, поэтому для интервьюера не зазорно делать на таких вещах акцент, потому что вы на время интервью - одна команда, которая строит архитектуру продукта. И это нормально не покрыть все аспекты в интервью, ведь оно проверяет технологический кругозор и опыт интервьюемого. Хороший собес вышел, свою компетентность парень показал. Гуд!
буквально кейс из одной из первых глав книги с кабанчиком (про твиттер), как раз сейчас читаю ее и очень приятно было послушать обсуждение этой задачи! спасибо!
Клиент стучится в gateway, который выполняет функции аутенификации, авторизации, балансировщик встроенный или внешний (консул какой-нибудь, как вариант)
Проблема проектирования от АПИ - кривые границы ограниченных контекстов, и как следствие на выходе распределенный монолит. Процесс проектирования должен строиться иначе. Бизнес требования(есть) -> Пользовательские требования (упущено) -> Стратегическое проектирование (упущено) -> Тактическое проектирование (очень сильно корявое) -> Оптимизации (кэш, репликации, CQRS, балансеры - сделано почему-то вперед всего)
"Стратегическое проектирование (упущено) -> Тактическое проектирование (очень сильно корявое)" Александр, а что почитать чтоб покрыть эту олбасть знаний?
Любопытно, как Кирилл стал тимлидом в Яндексе. По их меркам этого не достаточно, чтобы пройти архитектурную секцию, а на позиции дальше мидла они обязательны.
Спасибо за интервью. Было очень познавательно. Сильно видно, что кандидат имеет мало опыта проектирования - как дошло до схемы модулей и описания данных сразу запутался, при каждом уточнении начал придумывать костыли и как давай стрелки туда сюда рисовать в плоть до циклов. Начал про базы говорить про которые только слышал. Тоже полезно было, как не надо говорить ))
Тот случай, когда собеседуемый подготовлен теоретически, но не имеет практики. Сколько труда будет стоить грамотно организовать взаимодействие этих Image и Post services. Очевидно, что на первом этапе разработки их нужно объединить.
Можете обьяснить джуну, пожалуйста, в чем минус хранить в кэше не готовую ленту для пользователя из 20 постов, а хранить 20 последних постов пользователей и на основе того, что нам известны подписки пользователя, формировать его ленту?
если сравнить структуру двух кэшей, в каждой из структур мы делаем выбор в пользу того или иного преимущества с наименее болезненным негативным эффектом - id1 : { post1, post2, post3..} - id2 : { post1, post2, post3..} - id3 : { post1, post2, post3..} - id4 : { post1, post2, post3..} vs - id1: { post78, post3001, post134} - id2: { post901, post3001, post124} - id3: { post1101, post32, post10229} __________________ условное сравнение преимущества первого перед вторым будет следующим: - легко получает записи, если перейдёшь на страницу (условный ВК/twitter/Instagram -> ты увидел страницу, зашёл на неё и тебе из кэша подгрузили n первых постов определённого пользователя) - легко собирать ленту, если у тебя частые операции на подписку/отписку, при которой формирование ленты идёт путём merge операций по timestamp в постах (к примеру у тебя есть n друзей на основе которых в твоём кэше собрана лента, отписываясь от нескольких друзей тебе сложнее вычленить посты этих друзей в уже пред-подготовленной ленте редиса) - рассматривая поддержку редактирования поста (пользователь опубликовал запись, затем отредактировал текст к ней), и после редактирования мы снова должны пробежать по n подписчикам и обновить пост для каждого из них, чтобы в момент получения /feed мы увидели уже обновлённый пост, в то время как отношение id - { posts} просто на этапе запроса ленты по id друга вытянет актуальное состояние поста (не нужно каждое редактирование поста отправлять в n друзей, обновляя их пред-подготовленную ленту)
@@timmyyyyyyyyyyyydimkakoopa5732 Ты не дожен обновлять пост для каждого из них, пост обновяется в кеше. Клиент идет в кеш снова и забирает уже обновленный пост если надо, что сомнительно - так как нужна функция которая не загружает уже просмотренные посты. Иначе у тебя будет инстаграм показывать одни и те же посты все время. К тому же в реквайментах говорится что функции изменения поста не предусмотрено
Хочется уже увидеть хотя бы одно успешное прохождение архитектурки. Пока мнение такое, что это невозможно. Всегда можно сказать, что чего-то не хватило, т.к. тема бесконечна в отличии от времени интервью. Редко сразу в голову приходят идеальные решения. Секция выглядит весьма странно. Кажется, что еë используют для снижения самооценки кандидата и сбивания зп в оффере.
Зачем все это делать в реальном времени? Дается задание, дается время на реализацию, потом можно обсудить результат и в процессе обсуждения скорректировать элементы.
Это что-то вроде игры , как если бы рядовых строителей проектировщиков просили спроектировать то же здание за час. Никто бы не пошел после этого реальное здание по результатам строить. Это для проверки кругозора.
Архитектура - сразу космолет. Можно было сделать все гораздо проще, и не начинать архитектуру с CQRS, это то к чему приходят от безысходности, когда остальное уже не работает (репликации, кэш)
да, вот это "инженеры" - не могут байтики между размерностями сконвертировать, зато архитектуры инстараграмов обсуждают, слова умные заучили, ДАУ, МАУ, трафик, капасити... не удивлюсь, если у этих "архитекторов" за плечами лишь колледжи и гребля на галере N лет, после которых они посчитали себя архитекторами, назвались синьорами, тимлидами и думают, что действительно что-то умеют
аргумент в пользу таких инженеров прост: - расчет произвести можно в конвертере и калькуляторе, не столь важно, но отличие лишь в том, что если человек умеет рассчитывать безошибочно на листочке, это продвинет лишь на одну ступеньку вверх к систем дизайну на обсуждение непосредственно системы - знание constant hashing, sharding, LB, quadtree cassandra vs mongo (master/replica strategy) и прочее, сильно может повлиять на экономику проекта не судите по себе, если вы посчитали правильно, но другие нет. Видео носит информативный характер, очень хорошо, если вы что-то из него подчерпнёте полезное. Комментарий неадекватный по своей агрессивной интонации и наверняка, ваш болезненный и тернистый путь к вершине карьеры сказывается на вас травмой, но не все должны страдать как вы. ___________ повторюсь, на видео люди УЧАТЬСЯ, демонстрируют свои навыки и определяют свои знание на общей системе координат. Они не обязаны вам или кому-то еще. Любой желающий может поучаствовать в таком мероприятии, запишитесь и вы. Очень стыдно читать не поддержку коллеги, а попытки пристыдить. Укажите на ошибки, поправьте, скиньте ресурсы, есть другой подход в обучении
@@timmyyyyyyyyyyyydimkakoopa5732 судя по количеству слов в вашем комментарии, моё сообщение вас сильно задело :) ваши "аргументы", как и, вероятно, ваши сертификаты, бессмысленно комментировать. Метать перед свиньями бисер себе дороже.
биты в байты почему то умеют конвертировать ученики 5го класса, а вот сделать приложение - почему то не все ученики 5го класса :) не находишь ничего странного? да ты видимо и есть тот самый злой стажер который не может 5 лет уже найти работу хотя выучил всю "БАЗУ" но не устроился даже на 20 тыщ .... рублей в месяц
@@ИзяРобинович буду очень признателен, если увижу от вас ВАШУ ссылку на линкедин профиль. Задеть комментарием, вы конечно значительно преувеличиваете.. нет абсолютно никакого повода кому-то что-то доказать, чего о вас не скажешь
На мой взгляд систем дизайн это всегда разговор, как с коллегой, не всегда крайние случаи и острые углы архитектуры может продумать один человек, поэтому для интервьюера не зазорно делать на таких вещах акцент, потому что вы на время интервью - одна команда, которая строит архитектуру продукта. И это нормально не покрыть все аспекты в интервью, ведь оно проверяет технологический кругозор и опыт интервьюемого. Хороший собес вышел, свою компетентность парень показал. Гуд!
как хорошо что с точки зрения "Чистой архитектуры" можно и отложить вопросы по выбору DB )
что за сайт используется для рисования ?
буквально кейс из одной из первых глав книги с кабанчиком (про твиттер), как раз сейчас читаю ее и очень приятно было послушать обсуждение этой задачи! спасибо!
Коллеги, спасибо за комментарии.
Как всегда супер!
Клиент стучится в gateway, который выполняет функции аутенификации, авторизации, балансировщик встроенный или внешний (консул какой-нибудь, как вариант)
складываем 200 байт на описание с 500 кб на картинку и получаем 700кб. Браво!
ну это же mock-картинка)
12:17 Расчеты немного неверные, вы 200 байт прибавили к 500 КИЛОбайт
еще расчет хранилища сделан из того, что картинки и комменты будут лежать в одном месте, чего на практике не будет
и получилось 700 кБ)
Проблема проектирования от АПИ - кривые границы ограниченных контекстов, и как следствие на выходе распределенный монолит.
Процесс проектирования должен строиться иначе. Бизнес требования(есть) -> Пользовательские требования (упущено) -> Стратегическое проектирование (упущено) -> Тактическое проектирование (очень сильно корявое) -> Оптимизации (кэш, репликации, CQRS, балансеры - сделано почему-то вперед всего)
"Стратегическое проектирование (упущено) -> Тактическое проектирование (очень сильно корявое)"
Александр, а что почитать чтоб покрыть эту олбасть знаний?
А где здесь было про бизнес в начале? Бизнес это деньги. Пользовательские истории как раз покрыты.
P.S. Хотя Ок, было про аудиторию.
Все круто. Спасибо. Пожелание: зумить схему чтобы было видно о чем речь идет. Excalidraw позволяет зумить.
Костыль с подписчиками в качестве совета это странно
Любопытно, как Кирилл стал тимлидом в Яндексе. По их меркам этого не достаточно, чтобы пройти архитектурную секцию, а на позиции дальше мидла они обязательны.
Я так понял что тимлид не Кирилл, а Владимир =)
Спасибо за интервью. Было очень познавательно. Сильно видно, что кандидат имеет мало опыта проектирования - как дошло до схемы модулей и описания данных сразу запутался, при каждом уточнении начал придумывать костыли и как давай стрелки туда сюда рисовать в плоть до циклов. Начал про базы говорить про которые только слышал. Тоже полезно было, как не надо говорить ))
Жаль, не успели железо подсчитать
что это за программа в которой он рисует?
excalidraw
Разве систему разрабатывает один человек? Смысл вообще проводить такие эфемерные собесы далекие от рабочих процессов...
Тот случай, когда собеседуемый подготовлен теоретически, но не имеет практики. Сколько труда будет стоить грамотно организовать взаимодействие этих Image и Post services. Очевидно, что на первом этапе разработки их нужно объединить.
Почему всё-таки был выбран PostgreSQL для Post Service DB, а не MySQL, например? Только потому, что у собеседуемого он встречался в 80% случаев?
Потому что в яндексе нет пыхарей
@@sergeyz4591 разве MySQL используют только пыхари?
PostgreSQL мейнстрим в качестве RDBMS в энтерпрайзе.
@@dagerashenko а чем это обусловлено?
Можете обьяснить джуну, пожалуйста, в чем минус хранить в кэше не готовую ленту для пользователя из 20 постов, а хранить 20 последних постов пользователей и на основе того, что нам известны подписки пользователя, формировать его ленту?
если сравнить структуру двух кэшей, в каждой из структур мы делаем выбор в пользу того или иного преимущества с наименее болезненным негативным эффектом
- id1 : { post1, post2, post3..}
- id2 : { post1, post2, post3..}
- id3 : { post1, post2, post3..}
- id4 : { post1, post2, post3..}
vs
- id1: { post78, post3001, post134}
- id2: { post901, post3001, post124}
- id3: { post1101, post32, post10229}
__________________
условное сравнение преимущества первого перед вторым будет следующим:
- легко получает записи, если перейдёшь на страницу (условный ВК/twitter/Instagram -> ты увидел страницу, зашёл на неё и тебе из кэша подгрузили n первых постов определённого пользователя)
- легко собирать ленту, если у тебя частые операции на подписку/отписку, при которой формирование ленты идёт путём merge операций по timestamp в постах (к примеру у тебя есть n друзей на основе которых в твоём кэше собрана лента, отписываясь от нескольких друзей тебе сложнее вычленить посты этих друзей в уже пред-подготовленной ленте редиса)
- рассматривая поддержку редактирования поста (пользователь опубликовал запись, затем отредактировал текст к ней), и после редактирования мы снова должны пробежать по n подписчикам и обновить пост для каждого из них, чтобы в момент получения /feed мы увидели уже обновлённый пост, в то время как отношение id - { posts} просто на этапе запроса ленты по id друга вытянет актуальное состояние поста (не нужно каждое редактирование поста отправлять в n друзей, обновляя их пред-подготовленную ленту)
@@timmyyyyyyyyyyyydimkakoopa5732 Ты не дожен обновлять пост для каждого из них, пост обновяется в кеше. Клиент идет в кеш снова и забирает уже обновленный пост если надо, что сомнительно - так как нужна функция которая не загружает уже просмотренные посты. Иначе у тебя будет инстаграм показывать одни и те же посты все время. К тому же в реквайментах говорится что функции изменения поста не предусмотрено
Короче, я не понял, это видео про то как "надо делать" или как "не надо делать"?
Это просто видео
RPS рассчитан не верно) на порядок ошиблись) 5000000 / 5 / 86400 = 11,57
там было 50млн не 5😅
Хочется уже увидеть хотя бы одно успешное прохождение архитектурки. Пока мнение такое, что это невозможно. Всегда можно сказать, что чего-то не хватило, т.к. тема бесконечна в отличии от времени интервью. Редко сразу в голову приходят идеальные решения. Секция выглядит весьма странно. Кажется, что еë используют для снижения самооценки кандидата и сбивания зп в оффере.
- Какой DAU?
- Ну пусть будет 50 миллионов
Ну можно ли найти больший отрыв от реальной жизни, чем типовой сидиз собес?)
Зачем все это делать в реальном времени? Дается задание, дается время на реализацию, потом можно обсудить результат и в процессе обсуждения скорректировать элементы.
Потому что оценивается не результат, а путь к результату.
нет описания конкретных требований в итоге ты реализуешь не то что ожидалось или уйдешь в глубь одних вещей абсолютно не раскрыв другие
это интервью в диалоге и обсуждении
Это нихера не мок интервью. Скажем так - это вообще не интервью. Это больше учитель и ученик. Балун тянет за уши этого студента.
Довольно скудный выпуск. Интервьюер слишком часто соглашался со словами кандидата, не задавал каверзные и сложные вопросы, слабо.
например, какие вопросы вы бы задали? оценка интервьюера как раз не особо интересна...
ужасная архитектура, впрочем такие вещи не делаются "за час"
господи, дети не закончив школу в архитектора идут😂 крч что было бы если бы программисты строили дома
Это что-то вроде игры , как если бы рядовых строителей проектировщиков просили спроектировать то же здание за час. Никто бы не пошел после этого реальное здание по результатам строить. Это для проверки кругозора.
Архитектура - сразу космолет. Можно было сделать все гораздо проще, и не начинать архитектуру с CQRS, это то к чему приходят от безысходности, когда остальное уже не работает (репликации, кэш)
Да, согласен. На схемке `CQRS` выглядит красиво, а на деле -- заноза в заднице.
Мне кажется дизайн должны делать LLM для человека это слишком
В ответ на это Савватеев рекомендовал бы вам идти работать курьером))
@@AlexLexus42 Савватеев это тот, кто поддерживает избиение жены? Вот это авторитет, дааа
да, вот это "инженеры" - не могут байтики между размерностями сконвертировать, зато архитектуры инстараграмов обсуждают, слова умные заучили, ДАУ, МАУ, трафик, капасити... не удивлюсь, если у этих "архитекторов" за плечами лишь колледжи и гребля на галере N лет, после которых они посчитали себя архитекторами, назвались синьорами, тимлидами и думают, что действительно что-то умеют
аргумент в пользу таких инженеров прост:
- расчет произвести можно в конвертере и калькуляторе, не столь важно, но отличие лишь в том, что если человек умеет рассчитывать безошибочно на листочке, это продвинет лишь на одну ступеньку вверх к систем дизайну на обсуждение непосредственно системы
- знание constant hashing, sharding, LB, quadtree cassandra vs mongo (master/replica strategy) и прочее, сильно может повлиять на экономику проекта
не судите по себе, если вы посчитали правильно, но другие нет. Видео носит информативный характер, очень хорошо, если вы что-то из него подчерпнёте полезное. Комментарий неадекватный по своей агрессивной интонации и наверняка, ваш болезненный и тернистый путь к вершине карьеры сказывается на вас травмой, но не все должны страдать как вы.
___________
повторюсь, на видео люди УЧАТЬСЯ, демонстрируют свои навыки и определяют свои знание на общей системе координат. Они не обязаны вам или кому-то еще. Любой желающий может поучаствовать в таком мероприятии, запишитесь и вы. Очень стыдно читать не поддержку коллеги, а попытки пристыдить. Укажите на ошибки, поправьте, скиньте ресурсы, есть другой подход в обучении
p.s. [являюсь опытным backend разработчиком и сертифицированным архитектором]
@@timmyyyyyyyyyyyydimkakoopa5732 судя по количеству слов в вашем комментарии, моё сообщение вас сильно задело :) ваши "аргументы", как и, вероятно, ваши сертификаты, бессмысленно комментировать. Метать перед свиньями бисер себе дороже.
биты в байты почему то умеют конвертировать ученики 5го класса, а вот сделать приложение - почему то не все ученики 5го класса :) не находишь ничего странного? да ты видимо и есть тот самый злой стажер который не может 5 лет уже найти работу хотя выучил всю "БАЗУ" но не устроился даже на 20 тыщ .... рублей в месяц
@@ИзяРобинович буду очень признателен, если увижу от вас ВАШУ ссылку на линкедин профиль.
Задеть комментарием, вы конечно значительно преувеличиваете.. нет абсолютно никакого повода кому-то что-то доказать, чего о вас не скажешь