Какие есть с этим проблемы и как их решили в 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. Нужно, чтобы компиляция на такой большой базе кода работала быстро, а также тесты прогонялись быстро. Для этого вычисляется дельта, и прогоняется только подмножество тестов, на которые может повлиять ваше изменение.