Конференция по архитектуре IT-решений, на которой мы не только делимся опытом, но и создаем новые знания
Мы определяем цель конференции как «распространение имеющихся и создание новых знаний об архитектуре во всех ее проявлениях». Мы решили пойти дальше принятого формата и в дополнение к докладам, преследующим своей целью распространение знаний, попытаться найти решения еще не решенных проблем в архитектуре.
Я что-то не понимаю в полученной схеме. Если отдельные кубики "experiments service" и "experiments decision service" это реально разные сервисы, то это будто какой-то бред. "Эксперимент" это же одна и та же сущность одной и той же доменной области? Зачем делить это на разные сервисы, пускай этот энтити и дёргается разными видами пользователей? И то же самое можно сказать про "stats collector"-ы. Они же буквально ничего не будут уметь, кроме как принять на апи какие-то данные, смаппить их на другую модель и кинуть в продюсер. Зачем 2 отдельных сервиса? И с другой стороны очереди какой-то сервис под названием "датабэйс врайтэр" - это вообще супер странно. Вот мы в гит заходим, а у нас есть сервис "датабэйс врайтер" для сущности (и доменной области) А , "датабэйс врайтер" для сущности Б... Я допускаю что под словом "сервис" вовсе не сервис имелся ввиду, и на самом деле эти отдельные 6 сервисов, это всё деплойменты одних и тех же 2 сервисов с разными наборами логики, оперирующей одной и той же энтити. Но почему-то за интервью (за 1 час и 8 минут, что я посмотрел на данный момент) это ни разу не было упомянуто, и всем ОК. Ещё я допускаю, конечно, что я что-то не понимаю, и я всегда делал и понимал неправильно, а они делают правильно. Но не знаю... Очень сомнительным кажется мне, что когда у нас есть сущность "машина", надо делать отдельные сервисы "садильщик в машину", "заводильщик машины" и "ездок на машине". А потом ещё синкать через очереди состояние одной и той же машины между всеми сервисами...
- разработчики не понимают общий контекст - разработчики не понимают NFR - разработчики не понимают как все будет развертываться и тестироваться интересно, разработчикам комфортно работать с архитектором с таким отношением?
Много полезной информации, хороший доклад 📑 Репортер следует своим же заветам и верхнеуровнего визуально отображает + подробные устные пояснения, очень доходчиво
Наконец-то я понял, что меня напрягает. Нормальный разработчик "не любит" менеджеров, потому что он несет булшит. То есть, часто требования или неполные, или конфликтные и т.д, тоесть - противоречат здравому смыслу. Даже появилась прослойка людей, которые переводят с менеджерского на девелоперский. И вот я вижу как доменные эксперты начинают тоже говорить на птичьем и противоречить логике. Доменный слой - это кор. Про бизнес логику. Валидация входящих данных - это не бизнес логика. На вход в бизнес-сценарий должны уже поступать валидные данные. Далее - SOLID. SPR. Вы же вводите 1001 причину изменения. И т.д Ну тоесть менеджеры начинают подменять результат процессом - совещание, совещание про совещания, митинги, дейлики, обсуждения и т.д. И вот уже укушенные менеджерами ддд шники начинают создавать слои, абстракции, фабрики просто ради процесса. Таким образом стоимость и время разработки увеличиваеться, бизнес теряет деньги, но все заняты. Парадокс.
Больше всего корежило неправильное произношение слов 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. Но проблема даже не в этом, а в том что эти данные даже не используются например чтобы прикинуть количество машин и их размер и тп. Мне кажется что интервьюер не ставит сложные вопросы для соискателя а находится в фазе слушателя. Что тоже ок, но не дает ему представления о глубине и ширине знаний соискателя.
У меня когнитивный диссонанс - заявлять, что мидлов и джунов на секцию дизайна не зовём, но тех кого зовём оцениваем на эти уровни тоже. Вы бы хоть терминологию сменили)
Классный пайплайн отсеивания - мы успешно прошедшего секции языка и алгоритмов тянем на системный дизайн и если он не проходит, то не предлагаем ему, то на что он тянет, а просим прийти через полгодика со списком литературы😂
Ha-ha, classic. Сначала делаем алгоритмические интервью. Видим что это нахрен никому не сдалось. Но вместо того что-бы отменить, начинаем снимать видео, как проходить алгоритмические интервью. Потом удивляемся, что начинаем нанимать не талантливых программистов, а тех кто за...чил литкод и алгоритмы. Что же могло пойти не так? Вводим систем дизайн. Но опять видим, что норм люди отсеиваються. И вместо того, что бы переработать систему найма - начинаем выпускать видео, как проходить систем дизайн интервью так, как вам надо. Вы что не понимаете, что нормальный разработчик не будет тратить полгода-год только на то, что бы вытянуть ваши палки с колес при прохождении собесов. 80% толковых просто пройдут мимо. И будут правы.
от себя хочется сказать, что этот доклад - не хрен собачий... не хреновая тема... простите. единственный из всех архдейз который на 1.0х прослушан а не на 1.5х-2х. такая хрень казалось бы, но сколько за этим стоит хрЕновой боли... извините
Будто речь про МЕТУ, которая в Сбере вот прям для этого и используется. Кстати, это далеко не первая попытка такого подхода там - делегировать разработку логических подсистем продуктовым командам. Хз, как сейчас, но ещё год назад МЕТА - была боль для аналитиков продуктовых команд. Сама идея кстати отличная с КМД, но то, как это в Сбере внедрялось - трешак полнейший)) А доклад отличный.
Все эти собесы приходит из FAANG, а вот зарплаты не приходят:) Кто мне может рассказать зачем сеньору настолько доскональные знания system design? Когда он никогда не сможет принимать решения такого уровня. Ответ один, давайте сделаем собес такой, чтобы никто не мог пройти на 100%, тогда всегда можно срезать ЗП на 100к.
Вот тоже заметил, что в последнее время к сеньорам стали предъявлять требования как к Delivery Manager/Solution Architect/Team Lead и Project Manager, разве что до CTO и СEO не добрались) На мой взгляд, для сеньора достаточно грамотно реализовывать поставленные ему задачи в рамках проекта с применением указанных технологий
Собеседование оказалось проще, чем я представлял. Для человека, который хотя бы пару раз что-то проектировал и реализовывал самостоятельно должно быть не сложно. Просто мысли вслух о предметной области, ее моделях, подводных камнях и ожидаемых нагрузках. Я ожидал, что будет сильный уклон в тонкости работы отдельных компонентов системы: балансировки, меседжинга, масштабирования, репликации с синхронизацией в тонкостях, шардировании, кэшировании, проксирования и тд и тп.
подобные интервью - зло. я вообще категорически против таких интервью без предварительно согласованных 1) теребований 2) глоссария 3) пунктов оценивания (а в идеале ещё бы и согласованное оценивание в присутствии кандидата), потому что в итоге получается, что кандидата недослушали или он додумал какие-то требования интуитивно и забыл это проговорить и ещё куча и куча всякого субъективизма, который в итоге приводит к недооценённости кандидата. гораздо лучше просто поговорить про какие-то отдельные подходы или попросить рассказать про опыт и позадавать вопросы, так человек раскроется гораздо лучше и не будет биаса относительно кривых требований к тестовой архитектуре.
Хороший доклад, достаточно примитивный и понятный чтобы затекать в умы senior software developer и team lead, но недостаточно проработанный чтобы вовлечь в свою веру более крупную рыбу в свои сети :) Да и многие просто не сталкивались с проблемами onion desing, утечкой абстракций (abstraction leaking) и прочими прелестями bad system design.
Не связана с разработкой конкретно мобильеых приложений, но доклад очень интересный, спасибо. Понравилось, что даете структуру прохождения подобных собеседований и предлагаете опросник.
Не понимаю, зачем выходить за рамки ФТ и расписывать то, о чем тебя не просят. Если накидать сверху юзкейсов от себя, что можно сутки только о них говорить. Зачем отдельная база Payment DB? Упомянался паттерн transactional outbox - это как раз о том, чтобы когда Booking API создавало букирование в Booking DB, то в рамках той же транзакции создавалась запись (задание) на отправку сообщения в Payment Service. Иначе теряется весь смысл этого паттерна и транзакционность.
