Platform Program split стал ключевым шагом Uber, когда рост команды начал тормозить разработку. Это решение изменило архитектуру и организацию одновременно.
Проблема проявилась не на уровне кода, а на уровне взаимодействия команд. Когда инженерная организация Uber выросла примерно до 100 человек, разделение на backend, frontend и mobile стало узким местом. Любая фича требовала координации между несколькими командами, каждая со своим бэклогом и приоритетами. В результате скорость доставки падала, несмотря на рост команды. Параллельно существовал монолитный сервис API, который продолжал расти и регулярно становился причиной сбоев.
Решение началось не с микросервисов, а с изменения структуры команд. Был введён Platform Program split: кросс-функциональные program-команды стали отвечать за продуктовые фичи end-to-end, а platform-команды — за инфраструктуру и общие сервисы. Это снизило зависимость между командами и убрало необходимость “договариваться” на каждый релиз. Уже после этого шага микросервисная архитектура стала логичным продолжением, а не отправной точкой. Компромисс здесь очевиден: автономия команд растёт, но увеличивается сложность координации платформенных контрактов и стандартов.
Миграция к microservices происходила постепенно и под давлением гиперроста. Было введено простое правило: всё новое должно строиться вне монолита. Это позволило избежать блокировок между командами. При этом сам монолит продолжал расти — бизнес добавлял новые функции быстрее, чем происходила декомпозиция. Этот “грязный промежуточный этап” длился около двух лет. Важно, что Uber не пытался одномоментно переписать систему: вместо этого архитектура эволюционировала, покупая системе время на выживание.
Реализация сопровождалась дополнительными инженерными решениями. Появились внутренние инструменты, которые поддерживали масштабирование и разработку. Возникли требования к неймингу сервисов — из-за роста системы неформальные названия начали мешать навигации и онбордингу. Также стало очевидно, что стандартных инструментов недостаточно для такого масштаба, поэтому часть платформенных решений разрабатывалась in-house. Это типичный trade-off: ускорение разработки за счёт кастомных инструментов увеличивает стоимость их поддержки.
Отдельный аспект — переписывания (rewrites). В условиях hypergrowth они стали регулярной практикой. Каждое переписывание давало системе новый “запас прочности”, но не решало проблему навсегда. Это важное наблюдение: rewrite здесь — не ошибка планирования, а сигнал того, что бизнес опережает текущую архитектуру. В такой модели стабильность становится временным состоянием.
Результаты нельзя свести к одной метрике — в исходных данных их нет. Однако косвенные эффекты понятны. Platform Program split снизил организационные блокировки и ускорил delivery. Переход к microservices позволил командам развиваться независимо. При этом система стала значительно сложнее: количество сервисов измерялось тысячами, и даже спустя годы их число остаётся сопоставимым. Это подтверждает, что масштабируемость была достигнута ценой роста операционной сложности.
Дополнительно проявился ещё один эффект: архитектура и организация стали неразделимы. Platform Program split фактически задал границы сервисов и зон ответственности. Это согласуется с индустриальным наблюдением: структура команд напрямую влияет на структуру системы. В Uber это влияние было осознанным и управляемым.
Отдельно стоит отметить, что подобные решения работают только при высокой плотности инженерного таланта. Подход с автономными командами и распределённой архитектурой требует зрелых инженеров и сильных платформенных стандартов. Без этого система быстро деградирует.
В итоге Platform Program split можно рассматривать как прагматичный ответ на гиперрост. Это не попытка “идеальной архитектуры”, а способ убрать конкретные ограничения в скорости разработки. Микросервисы в этой истории — следствие, а не причина. И ключевой урок здесь в том, что масштабирование требует синхронных изменений в архитектуре, процессах и структуре команд.