FAANG Master

IOI 2026 В Ташкенте прошел межнар школьников по информатике. Результаты: https://stats.ioinformatics.org/results/2026 Официальный медальный зачет по странам не составляется. Также участники из некоторых стран не выступали под флагами своих стран (Россия, Белоруссия, Израиль и т.д.). Разбивка по странам: https://stats.ioinformatics.org/contestants/2026 В конце там есть участники из этих стран. Владислав Жиганов из России занял абсолютное второе место: https://stats.ioinformatics.org/people/8665 Попросил нейронку сделать неофициальный зачет по медалям как на олимпийских играх и при равном числе медалей по сумме набранных баллов. Получившаяся первая 20ка: 1) Китай, 3-1-0, 1736.83 2) Израиль*, 3-0-1, 1499.01 3) Малайзия, 2-2-0, 1513.21 4) Россия*, 2-2-0, 1513.20 5) США, 2-2-0, 1487.67 6) Япония, 2-1-1, 1517.09 7) Корея, 2-1-1, 1353.45 8) Гонконг, 2-1-0, 1317.18 9) Польша, 2-1-0, 1312.10 10) Казахстан, 1-3-0, 1456.58 11) Турция, 1-2-1, 1350.16 12) Австралия, 1-2-0, 1314.80 13) Тайвань, 1-2-0, 1299.82 14) Украина, 1-2-0, 1286.81 15) Вьетнам, 1-2-0, 1244.42 16) Бразилия, 1-1-2, 1273.75 17) Румыния, 1-1-2, 1269.04 18) Беларусь*, 1-1-2, 1248.34 19) Болгария, 1-1-2, 1215.40 20) Филиппины, 1-0-2, 944.13 * — выступали без национального флага Составы сборных США: https://stats.ioinformatics.org/delegations/USA/2026 И Великобритании: https://stats.ioinformatics.org/delegations/GBR/2026

В свое время я закончил МФТИ. Относительно непростой вуз для обучения. Закончил неплохо. За время обучения выработал подход к подготовке к экзаменам, который часто применял после окончания вуза. Например, когда решил стать программистом или когда решил заботать алгосы, чтобы поработать в фангах. Подход следующий. Обычно, на подготовку к экзамену выделялось 4 дня. Для теоретических экзаменов давали список вопросов (билеты). Обычно, это 30-80 тем. Я старался разделить этот список на 3 части и ботать в день эту одну треть. Например, если 30 вопросов, то в день ботал 10 вопросов. Ботал примерно 12-14 часов в день. Каждый день был устроен примерно так. Читаю/изучаю какой-то вопрос по лекциям, книгам и т.д. Стараюсь разобраться пока не понимаю все детали. Далее воспроизвожу этот вопрос на бумаге с формулами и проговариваю про себя ответ на вопрос. И так по всем вопросам, которые я запланировал на день. В конце дня повторял все изученные вопросы за день. Иногда мы проговаривали эти темы вместе с соседями по общаге. Также спрашивали друг друга непонятные вещи, с которыми не смогли разобраться сами. На 4 день, я снова повторял все изученные билеты и доучивал все, что не успел за предыдущие три дня. Часто недоучивал несколько последних билетов, т.к. не хватало времени и/или капасити памяти/мозга. На них я писал бомбы и брал с собой. За все время они мне пригодились 1 раз. Выпал билет, который я не учил и я воспользовался бомбой. К письменным экзаменам подход похожий. Только вместо билетов, там типы задач. Подготовка была чуть проще, т.к. в течении семестра мы сдавали задания, где прорешивали десятки типовых задач. К письменному экзамену я находил варианты прошлых лет, которые были во внутренней сетке, и прорешивал с десяток другой задач на каждую тему (по матану, дифурам, общефизу и т.д.). Аналогичный подход я применял, когда решил изучить алгосы 11 лет назад. Я никогда не участвовал в олимпиадах по программированию и изучал все буквально с нуля. Основа подготовки: выяснение основных типов задач, изучение теории и подхода к решению данного типа задач, прорешивание большого числа задач на каждую тему. При этом важно попробовать сначала решить самостоятельно, потом разобраться с решением и его воспроизвести. И далее повторять уже решенные задачи с увеличивающимся интервалом. Сначала сразу после решения. Потом через несколько дней/неделю, потом через месяц, потом через год, потом через несколько лет/перед следующей подготовкой к собесу в другую компанию. Вначале процесс забывания максимален, далее он постепенно замедляется и задача/подход к решению остается надолго в долгосрочной памяти. Самостоятельное прорешивание вначале позволяет глубже погрузиться в детали задачи, ее сложность именно для вас. Это сделает разбор решения более персонализированным, будет вызывать эмоциональный отклик на моменты, с которыми у вас были сложности. И поэтому вы лучше запомните задачу.

Документалка про Java В продолжение темы документалок, вышла документалка про Java. Трейлер: Official Trailer Анонс: Java: The Documentary is Coming Soon Документалка: The Java Story

Ford наняла обратно уволенных инженеров по качеству Ранее Ford внедрила систему, основанную на AI, для контроля качества производства. Благодаря, чему уволила сотни инженеров. Внедрение AI системы привело к росту количества брака и отозванных автомобилей. Сейчас Ford наняла обратно 300+ опытных инженеров по качеству работать совместно с этой AI системой.

Еще несколько рекомендаций по литературе

Hope Driven Development становится все актуальней и актуальней с появлением AI.

Рейтинг городов Европы для Digital Nomad Это для тех, что зарабатывает, работая на полной удаленке и имеет возможность работать откуда угодно. Из 19 городов, я исключил те, где нет никакой возможности получить визу, если вы не работаете в этой стране. При расчете рейтинга я учитывал: стоимость жизни, стоимость недвиги, легкость получения Digital Nomad Visa, климат, медицину, преступность, язык. Итоговый рейтинг: 1) Валенсия. 32 балла. Дешево, дешевая недвига, легко получить Digital Nomad Visa, море, солнце, хорошая медицина, низкая преступность. 2) Порту. 30 баллов. Аналогично Валенсии. Но нет моря (есть океан), чуть дороже недвига. 3) Кипр (Лимассол). 28 баллов. Подороже, чем Валенсия. 4) Лиссабон. 28 баллов. Дороже чем Валенсия, особенно недвига. 5) Барселона. 28 баллов. Дороже Валенсии, выше преступность. 6) Мадрид. 27 баллов. Как Барселона, но лучше с преступностью и нет моря. 7) Прага. 26 баллов. Сложнее получить такую визу. Нужно ИП открывать в Чехии. Дорогая недвига. 8) Франкфурт. 26 баллов. Сложнее получить такую визу. Дорогой город. Нет моря. 9) Мюнхен. 26 баллов. Аналогично Франкфурту. 10) Берлин. 25 баллов. Аналогично Франкфурту, но чуть дешевле. Также выше преступность, хуже медицина. 11) Варшава. 25 баллов. Нет моря, сложнее получить такую визу, дорогая недвига. 12) Дубай. 25 баллов. Жарко, дорого. 13) Париж. 24 балла. Сложно получить такую визу. Очень дорого. Нет моря.

В продолжении рейтинга городов Европы. Рейтинг по покупке недвижимости. Для тех, кому важна только возможность купить недвижимость. Для каждого города я вычислил медианную зп синьера в месяц после уплаты налогов. И месячный платеж по ипотеке за сферическую недвигу в вакууме (75 кв. метров) при 20% первоначальном взносе и 25 годах выплат. 1) Дубай. 15%. 2) Валенсия. 22%. 3) Кипр (Лимассол). 25% 4) Мадрид. 33% 5) Барселона. 36% 6) Брюссель. 36% 7) Цюрих. 38% 8) Порту. 42% 9) Варшава. 42% 10) Амстердам. 47% 11) Берлин. 47%. 12) Лондон. 47% 13) Стокгольм. 54% 14) Лиссабон. 56% 15) Прага. 58% 16) Франкфурт. 59% 17) Мюнхен. 69%. 18) Париж. 72% 19) Люксембург. 76%. Это при условии, что вы и работать будете в том же городе (а не удаленка на компанию из другой страны). Также часто есть обходные пути. Например, кажется, что в Люксембурге невозможно купить недвигу. Но многие покупают не в самом городе, а в соседних городах. Там всю страну за 2 часа можно объехать. Также есть возможность купить недвигу в несколько раз дешевше по специальным программам. Если это ваша первая недвига, вы ее не можете никому сдавать, а только в ней жить и продать вы ее можете только по цене покупки изначальному продавцу (лэндлорду). Знаю людей кто купил на условные 300-400 тысяч евро дом на 200 квадратов в 40 минутах от Люксембурга.

Топ городов Европы для миграции программиста в 2026. Долгосрочная миграция с возможностью работы в BigTech/FAANG Включил 18 городов Европы и Дубай. США, Южную и Центральные Америки, Азию, Австралию не рассматривал. Сделаю несколько топов из этих городов, т.к. разные города хороши под разные типы и цели миграции. Сегодняшний топ фокусируется на долгосрочной миграции, с целью получения гражданства, покупки недвиги, долгосрочной жизни и работы в разных компаниях, которые нанимают в этом городе. Не для тех кому нужно срочно уехать куда-то. Не для тех, кто хочет жить у моря, не важно где, работая на удаленке. А также рассматривает возможность поработать в FAANG/BigTech-компаниях в этом городе. Не для тех, кто хочет выйти на пенсию, живя на инвестиции (FIRE). Я проанализировал 13 различных параметров (получение гражданства, зп, стоимость жизни, стоимость недвиги по отношению к зп, климат, преступность, медицину, образование, наличие FAANG, удобство жизни зная только английский и т.д.), составил скоринг метрику и вот что у меня получилось: 1) Лондон. Был сам удивлен. 38 баллов. Хорош в: получении гражданства, не нужно отказываться от первого гражданства. Много вакансий, много FAANG/BigTech. Английский. Топ университеты. Средний/ниже среднего в: стоимости жизни, преступности, стоимость покупки недвижимости. 2) Цюрих. 34 балла. Хорош в: безопасность, образование, FAANG/BigTech компании, распространенность английского, высокие зп по отношению к стоимости жизни и стоимости недвиги. Плох в: получении гражданства, мало вакансий, кроме FAANG. 3) Берлин. 32.5 балла. Хорош в: получении гражданства. В остальном нет откровенно плохих метрик, по всем средний/выше среднего. 4) Дубай. 32.3 балла. Хорош в: стоимость жизни по отношению к зп, налоги, стоимость недвиги по отношению к зп. Плох в: нельзя получить гражданство, климат, нет фангов. 5) Амстердам. 31.7 балла. Во всем чуть выше среднего. Ниже среднего: не много вакансий, стоимость жизни и недвиги по отношению к зп. 6) Варшава. Был удивлен. 31.5 балла. Хороша в: стоимости жизни по отношению к зп, относительно много вакансий, есть фанги. Плоха в: язык, получение гражданства. 7) Кипр (Лимассол). 29.7 балла. Хорош в: получении гражданства. По большинству других параметров выше среднего. Плох в: нет фангов, не очень много вакансий. 8) Мюнхен. 29.5 баллов. Хорош в: получении гражданства, безопасность, медицина, топ универы, фанги. Плох: высокая стоимость недвиги по отношению к зп. 9) Барселона. 28.5 баллов. Хороша в: климат, медицина, цена недвиги. Плохо: гражданство, язык, преступность. По большинству остальных средне. 10-11) Мадрид. 28.3 балла. Как Барселона, но похуже климат, получше преступность. 10-11) Брюссель. 28.3 балла. Хорошо: гражданство, медицина, образование, покупка недвиги. Плохо: мало вакансий, нет фангов, преступность. 12) Франкфурт. 28 баллов. Хорошо: гражданство, преступность, медицина, образование. Плохо: мало фангов, мало вакансий, стоимость недвиги и стоимость жизни. 13) Париж. 25.3 балла. Хорошо: гражданство, медицина, топ универы. Плохо: язык, стоимость жизни и недвиги по отношению к зп. 14) Стокгольм. 24.8 балла. Хорошо: распространенность английского, образование, медицина, безопасность. Плохо: стоимость жизни и недвиги, получение гражданства. 15) Люксембург. 23.8 балла. Я там жил, лучшее место, но не очень хорошо для долгосрочной миграции программиста. Хорошо: гражданство, безопасность, медицина, образование, английский. Плохо: мало вакансий, кроме амазона, высокая стоимость жизни и недвиги. 16) Валенсия. 22.8 балла. Хорошо: безопасность, медицина, образование, климат, покупка недвиги. Плохо: гражданство, нет фангов, язык, мало вакансий, маленькие зп. 17) Прага. 22.1 балл. Хорошо: безопасность, медицина, образование. По большинству остального - сильно ниже среднего. 18) Порту. 20.5 баллов. Хорошо: безопасность, медицина, климат. По остальному - сильно ниже среднего. Хорошо, если вы не зарабатываете в Португалии, а там живете на инвестиции или полной удаленке/фрилансе. Но об этом у меня будет отдельный топ. 19) Лиссабон. 19 баллов. Почти как Порту, но чуть хуже.

Основные причины багов в проде Это мой личный рейтинг причин на основе работы в 5 компаниях в 4 странах в течении почти двух десятков лет: 1) Качество разработчиков. В начале карьеры я думал, что основная причина - отсутствие процессов. Но потом на практике убедился, что это не так. Какие бы не были процессы (код ревью, тестирование, мониторинг и т.д.) вы не сможете всего предугадать и сделать защиту от дурака от всех возможных случаев. Процессы помогают, но при низком качестве разработчиков это не спасет от всех возможных случаев. В Мета процессов почти нет, тестирование минимально, при этом количество багов не такое большое. Если вы будете нанимать верхние персентили разработчиков по качеству (что бы это не значило), то они будут сразу писать правильно и без багов. 2) Конфигурации. Это вообще топ причина для фангов. Что в Амазоне, что в Facebook/Meta sev0, Large Scale Event аутеджи чаще всего случаются из-за деплоя конфигураций в прод. Конфигурации практически никак не тестируются, быстро деплоятся в прод (минуты). И никто не знает как они повлияют на систему. В них нет/мало проверок, как автоматических так и ручных. Нет особых процессов. Нет интуиции и опыта, как с кодом. Поэтому качество программистов не всегда спасает. 3) Проблемы версионирования/API. Это актуально, если у вас не монолит. Если вы дергаете какую-то зависимость, но ее поведение изменилось и стало не таким каким вы его ожидаете или изменился протокол взаимодействия, то это приводит очень часто к багам. Это типичная проблема микросервисных архитектур, особенно, когда зависимостей очень много. 4) Miscommunication, неправильное понимание задачи/бизнес логики. Тут часто не спасают ни тесты, ни качество программистов. Тесты не спасают, т.к. если вы не правильно поняли как это должно работать, то и в тесте вы будете проверять, что оно работает как ожидаете вы, а не как правильно. Качество программиста тут только гарантирует, что оно будет работать как вы ожидаете, но не как правильно. 5) Проблемы зависимостей. Это то, что сложно контролировать. Если ваша зависимость перестала работать, то тут только нужно убедиться, что ваша компонента fault tolerant и реализованы все нужные механизмы для сокращения blast radius. Например, retry, rate limiting/throttling, circuit breaker, bulk head и т.д. 6) Отсутствие достаточного тестирования. Это только на 6 месте у меня, т.к. при хорошем качестве программистов, это не обязательное условие. При низком качестве, если вы хотите минимизировать число багов - это must have. Если человек не глубоко понимает как работает, написанный им, код. Не видит все edge-cases. Не имеет опыта, не предвидит потенциальные проблемы. Если человек не внимателен к деталям, если он не умеет делать прогрессивный ролаут, мониторить, находить проблемы и их исправлять, пока они не станут влиять на систему, то все возможные тесты обязательны. 7) Отсутствие прогрессивного ролаута и мониторинга в проде. Тестировать и воспроизводить условия прода в тестах часто очень сложно. Поэтому иногда проще задеплоить это в прод, но добавить feature flag и ограничить, кто может пользоваться этим функционалом. Например, можно начать с одного пользователя или маленького процента пользователей. Посмотреть как это будет работать в условиях прода, собрать и проанализировать все метрики и потом уже разворачивать на больший процент пользователей. 8) Сложное сочетание редких событий/медленная деградация системы. Обычно, это сложно покрыть тестами заранее. Часть проблем можно отловить нагрузочным/перфоманс тестированием, но не всегда. Т.к. длительность теста ограниченна по времени и баг может воспроизводится в каких-то особенных условиях. Например, у вас какая-то проблема в коде с многопоточностью, или у вас есть подтекание памяти, которое не происходит на масштабах времени работы нагрузочного теста. Тогда проблема может возникнуть в проде через большой промежуток времени при определенных условиях, которые сложно предусмотреть во время тестирования. Также частично это покрывается качеством программистов, у кого есть опыт и интуиция возможных проблем, но далеко не всегда. Обычно, такие проблемы находят в проде, долго инвестигируются и потом уже под них добавляют какой-то особенный тест. 9) Отсутствие или плохой code review. Одна из задач code-review это найти баги. Это хоть и не основная, но важная часть. Когда пару других разрабов посмотрят на ваш код, они могут заметить баги, которые не заметили вы. Из всех компаний, где я работал, это реально работало только в Amazon. Во многих других компаниях code review или отсутствовал, или был формальным. Но чаще это просто был тул для создания холиваров и конфликтов между программистами и ничему не помогал. Каков ваш опыт? Почему у вас в компании чаще всего возникают баги?

Heatwave в Лондоне На этой неделе в Лондоне ожидается сильная жара. До +38°C. Обычно, такую погоду в UK называют heatwave (хитвейв). При этом жара в UK переносится сильно хуже, чем в других странах. Тут даже температура выше +25°C уже не сильно комфортная. Это связано с несколькими факторами: 1) Отсутствие кондиционеров в домах. Тут практически не бывает кондиционеров в жилых домах. Кондиционеры есть, в основном, только в офисах и магазинах. Сверлить фасад здания и повесить кондиционер вам никто не даст. 2) Дома - термосы. Дома строились с расчетом на накопление и удержание тепла внутри. У них хорошая теплоизоляция. А также стены сделаны из материала, который хорошо нагревается и долго держит тепло. Это хорошо в прохладную погоду, но не летом. Тут, в отличие от Германии и других стран Европы, не холодно зимой в домах. В Дюссельдорфе и Люксембурге, где я жил до Лондона, было сложно получить температуру выше 19-20 градусов зимой без больших счетов на коммуналку. В Лондоне такой проблемы нет (ну или не так заметна). Но летом это превращается в ад. Дом нагревается в жару и даже после того как жара спадает, стены продолжают еще долго отдавать тепло внутрь и удерживать от потерь наружу. На улице уже может быть 20, а в доме все еще больше 25. 3) Нет внешних ставень. Во многих странах Европы на окнах есть внешние ставни. Закрывать их можно изнутри дома. При этом они полностью блокируют свет, благодаря чему не нагревается само окно и помещение внутри. В Лондоне такого нет. Более того, во многих квартирах окна от потолка до пола, т.е. у вас такой аквариум, который сильно прогревается солнцем со всех сторон. В Люксембурге у меня в квартире были ставни, хотя страна не южная, типа Испании. Это было особенно хорошо ночью, можно было создать полную темноту в помещении на ночь. И все это хорошо сочеталось с +19°C внутри. Спать было заметачельно. 4) В жару очень часто полностью чистое небо. Не смотря на репутацию туманного Альбиона и дождливой страны, тут бывает очень солнечно. При этом на небе нет ни одного облачка. При таком палящем солнце, даже +25°C уже кажется жарой. А в сочетании с квартирами аквариумами, это делает жару внутри помещений невыносимой.

Starbucks отказался от AI системы для инвентаризации В сентябре 2025 года новый CEO компании Брайан Никкол решил побороть вечную проблему нехватки ингредиентов в кофейнях. В 11 тысячах точек США и Канады внедрили систему Automated Counting (от разработчика NomadGo). Бариста должны были просто навести планшет с камерой на полки с сиропами, молоком и кофе, а нейросеть с помощью компьютерного зрения должна была сама всё посчитать и заказать то, что заканчивается. На практике: Нейросеть регулярно путала разные виды молока (например, обычное с миндальным или соевым). ​Система не видела некоторые позиции или, наоборот, считала один пакет за два. ​Из-за постоянных галлюцинаций ИИ бариста приходилось тратить массу времени на ручную перепроверку данных, что полностью убивало смысл автоматизации. После 9 месяцев мучений, в итоге, они отказались от системы и перешли на ручной учет. При этом, они недавно ввели KPI для своих корпоративных сотрудников по использованию AI (токенмаксинг) и привязали это к премиям и т.д.

Какие есть с этим проблемы и как их решили в Facebook/Instagram? 1) Производительность системы контроля версий. Если у вас очень много кода в одном репозитории как в Meta (миллионы файлов, десятки, если не сотни миллионов строк), то система контроля версий может на справиться по производительности. Поэтому Мета сделала свою систему контроля версий на основе Mercurial (git не справлялся с такими масштабами). 2) Feature Flags. Из-за trunk-based development у вас деплоится множество функционала в промежуточном состоянии. Для этого вам нужно иметь возможность ее включать и выключать в проде, проводить тестирование в проде и т.д. Для этого вам нужно активно использовать feature flags. 3) Привязка к одному языку программирования. Это неустранимая особенность. Приходится писать на том языке, на котором написан монолит. 4) Влияние проблем в одной фиче на другую/независимое масштабирование. Если одна функциональность стала работать плохо (потреблять много памяти, бросать ошибки, потреблять много процессорного времени и т.д.), то это может повлиять на работоспособность другого функционала, т.к. весь функционал живет на одном и том же сервере (т.к. это монолит). Это решено на уровне виртуальной машины/контейнера приложений. В Python у вас создается несколько отдельных процессов. Которые способны обрабатывать запросы независимо друг от друга. Число процессов зависит от числа ядер процессора. Процессы не шарят между собой память. Их можно независимо друг от друга мониторить, убивать и перезапускать. В hacklang и hhvm процесс один, но имеет множество потоков, которые имеют изолированную память, которую можно независимо друг от друга ограничивать. Потоки более легковесные, чем отдельные процессы. Но при этом они не шарят память между собой. В Java такое реализовать не получится. Там также один процесс и отдельные потоки на каждый запрос. Но потоки используют одну и туже память (Java Heap). 5) Проблемы с ownership кода. Из-за того, что весь код в одной большой куче, сложно разграничивать, кто отвечает за тот или иной код. В Meta эта проблема решена плохо. Тут есть и плюсы и минусы. С одной стороны, вы не ограничиваетесь кодом своей команды и можете при необходимости изменить любой код. Но важно, чтобы те, кто отвечает за этот код как минимум, проревьюили это изменение. В Meta с этой целью к каждому файлу добавляется специальная аннотация/тег - какая команда владеет этим кодом. И при его изменении, автоматически в код ревью добавляются люди из нужной команды. 6) Сложно засетапить CI/CD. Нужно, чтобы компиляция на такой большой базе кода работала быстро, а также тесты прогонялись быстро. Для этого вычисляется дельта, и прогоняется только подмножество тестов, на которые может повлиять ваше изменение.

Почему самые высоконагруженные веб приложения мира это не всегда микросервисы? Многие компании, которые разрабатывают самые высоконагруженные приложения, с миллиардами запросов в секунду, используют монолиты и монорепы. Ярким примером является Facebook и Instagram. В бэкенде это монолиты. Конечно, у них есть большое число других компонент, которые вынесены в отдельные сервисы, но основной backend, который принимает и обрабатывает запросы от фронтенда (веба или мобильного приложения), содержит бизнес логику - это монолит. Backend Facebook изначально был написан на PHP в 2004 году. Далее его плавно мигрировали на собственный язык hacklang и собственную виртуальную машину hhvm. При этом он остался, по большей части, колоссального размера монолитом. Аналогично, Instagram написан на python (django). Основная часть все еще остается монолитом. Оба сервиса имеют миллиарды пользователей и обрабатывают невероятное число запросов в секунду. При этом они обладают колоссальной отказоустойчивостью и скорость разработки сервисов огромная. Время от того, как вы запушили комит до деплоя в prod проходит несколько часов. Более того, весь код этих приложений находится в монорепе и используется trunk-based development. Т.е. все изменения сразу делаются в основной ветке разработки. Почему так? Какие это дает преимущества? Монорепа: 1) Проблема версионирования API решается на уровне компилятора. Если вы меняете какое-то API, то вы не сможете запушить это изменение в trunk до тех пор, пока не измените все call site (все места, где это API вызывается). Вам не позволит компилятор, ваш код просто не скомпилируется. Если у вас множество репозиториев, то изменение API в одном месте не блокирует вас запушить это изменение. Вы создадите новую версию вашего API. Всем клиентам нужно про это узнать, и делать процесс миграции на новую версию. Нужно менять код, зависимости и т.д. Очень часто это приводит к багам в проде. Когда клиент ожидает одного поведения или семантики API, а в проде уже задеплоена другая версия. 2) Полностью решается проблема dependency hell. Проблемы зависимостей на разные версии одной и той же библиотеки со стороны разных зависимостей вашего модуля. Круговые зависимости и т.д. Тут все решается автоматически на уровне компилятора. 3) Легкий поиск по коду. У вас весь код под рукой. Если он проиндексирован можно легко найти любой интересующий вас код. В Амазоне отдельные репы. Там целая наука работы с зависимостями. Есть свои тулы, концепции и т.д. Там есть тул brazil, понятие version set и много всего другого. Это постоянно приводит к затыкам с зависимостями, багам в проде из-за версионирования. Часто пуш сторонней библиотеки может заблокировать ваш CI/CD пайплайн, т.к. у вас поломались зависимости. Монолиты: 1) Высокая производительность. В микросервисах вызов функции происходит по сети, что работает за миллисекунды. В монолитах вызов происходит в рамках одного процесса и работает за наносекунды. 2) Нет проблемы версионирования API в проде. Это решается на уровне компилятора. Это типичная проблема микросервисов. 3) Легко тестировать. Вы можете протестировать все e2e. В микросервисах часто очень сложно или не возможно протестировать приложение e2e. Вы можете протестировать свою компоненту, но не весь функционал в целом. Особенно, если у вас под 100 тысяч микросервисов, как в условном Amazon. Trunk-based development: 1) Отсутствие Merge-Hell. Если вы разрабатываете крупную фичу в отдельной ветке, ее потом сложно мержить в trunk. Мелкие и частые изменения предотвращают тяжелые конфликты вмерживания. 2) Можно сделать реальный и быстрый CI/CD. В Мета любое изменение вмерживается, компилируется, тестируется и деплоится в прод за несколько часов. Не нужно делать долгие, сложные и редкие релизы.