Какой самый сложный технический проект, в котором вы участвовали?

Самый сложный технический проект, в котором я участвовал

Этот вопрос проверяет мой опыт справления со сложностью, управления командой, и решения проблем в реальности. Расскажу историю.

Контекст: Миграция на микросервисную архитектуру

Компания: B2B SaaS платформа для управления поставками (Supply Chain).

Проблема: Монолитное приложение, построенное за 5 лет:

• 500k строк кода на Python/Django
• Одна большая база данных (PostgreSQL)
• Сложная логика, плотно связанная
• Когда я делаю изменение в одной части, это часто ломает другую
• Development был замораживающе медленным

Боль PM:

• Фичи требуют 2-3 месяца разработки
• Конкуренты с микросервисами выпускают фичи в 2-3 недели
• Team дробилась на разные domains (payments, inventory, logistics)
• Нельзя нанимать отдельные team для разных domains, потому что всё связано
• Даже small bug fixes требуют разработчика, который знает всю систему

Решение: Миграция на микросервисную архитектуру

План: Перевести монолит на ~10 микросервисов:

• Order Service
• Inventory Service
• Payment Service
• Logistics Service
• Notification Service
• And others...

Каждый сервис:

• Owned by separate team (5-7 engineers)
• Own database (database per service pattern)
• Own deployment
• API для коммуникации

Почему это сложно (не просто technically, но в целом)

1. Complexity уровня

• Не просто код разбить, нужно изменить архитектуру
• Нужна Service discovery
• Нужна Async communication (message queues)
• Нужно distributed transaction management
• Нельзя больше использовать SQL JOINs между сервисами

2. Team coordination

• 50+ engineers в одной команде
• Нужно разбить на 10 teams
• Каждая team с own PM, tech lead, engineers
• Нужна coordination между teams
• Риск: teams работают на разных скоростях

3. Timeline

• Нельзя остановить разработку на 6 месяцев
• Нужно "перестраивать самолёт в полёте"
• Новые фичи нужно разрабатывать ОДНОВРЕМЕННО с миграцией
• Это усложняет всё

4. Risk

• Если миграция пойдёт плохо, можем потерять пользователей
• Если в процессе будет downtime, это критично для B2B
• Данные важны, нельзя потерять ничего

5. Technology unknowns

• Многие engineers не имели опыта в микросервисах
• Нужно выучить новые инструменты (Kubernetes, Docker, gRPC, message queues)
• Нужно time на обучение

Как я (как PM) справился

Шаг 1: Research и planning (3 месяца)

Разработал полный план миграции:

• Какие сервисы нужны
• Какие данные в каком сервисе
• API contracts между сервисами
• Timeline (12-18 месяцев)
• Risk assessment

Интервью с CTO и tech leads: "Это правильный path? Есть ли альтернативы?"

Ответ: "Микросервисы это правильно, но нужно делать этапами."

Шаг 2: Phase-based approach

Вместо "разбиваем всё сразу", делаем фазы:

Phase 1 (Months 1-4): Foundation

• Создаём infrastructure (Kubernetes, service mesh)
• Создаём shared libraries для communication (protobuf, gRPC)
• Миграция Payment Service (самый independent сервис)
• Это даёт нам experience

Phase 2 (Months 5-8): Core services

• Inventory Service
• Order Service
• Database migration для этих сервисов
• Это трудно, но основано на phase 1 learnings

Phase 3 (Months 9-12): Dependent services

• Logistics Service
• Notification Service
• Интеграция с core services

Phase 4 (Months 13-18): Cleanup & optimization

• Удаление остатков монолита
• Оптимизация inter-service communication
• Performance tuning

Шаг 3: Parallel feature development

Не заморозили разработку новых фич.

Использовали Strangler Fig pattern:

• Новые фичи пишут в микросервисе, когда он готов
• Старые фичи continue в монолите
• Постепенно монолит становится меньше

Это позволило:

• Не терять revenue (продолжаем выпускать фичи)
• Показать value миграции (новые фичи быстрее)
• Не разочаровать sales team (они видят новые features)

Шаг 4: Team reorganization

Вместо одного team of 50, создали:

• Order Squad (8 engineers, 1 PM)
• Inventory Squad (8 engineers, 1 PM)
• Payment Squad (6 engineers, 1 PM)
• Logistics Squad (7 engineers, 1 PM)
• Platform Team (10 engineers, infrastructure)
• (other teams)

Каждая team owns own сервис, own database, own deployment.

Это был большой shift в org structure.

Шаг 5: Risk mitigation

Database migration risk:

• Нельзя потерять данные
• Использовали change data capture (CDC)
• Старая база синхронизируется с новыми базами в real-time
• Если что-то пойдёт плохо, можно откатиться

Backward compatibility:

• Каждый новый сервис expose старый API
• Монолит может continue использовать старый API
• Постепенно миграцию старые clients на новый API

Monitoring и observability:

• Когда много микросервисов, нужна visibility
• Внедрили distributed tracing (Jaeger)
• Нужна better logging и metrics

Шаг 6: Communication и alignment

Это biggest challenge.

Weekly syncs:

• Все PMs встречались еженедельно
• Обсуждали dependencies между сервисами
• Разрешали conflicts

Architecture decision records (ADRs):

• Документировали все большие решения
• Это помогало teams понять reasoning

API contracts:

• Defined contracts для inter-service communication
• Teams могут разрабатывать independently

Sharedслак channel:

• Основной channel для questions
• Нужно быстро решать blockers

Challenges, которые возникли

Challenge 1: Order Service блокировала остальных

Order Service самая сложная (много логики). Когда она не была готова, другие services не могли прогрессировать.

Решение: Разбили Order Service на несколько smaller services (OrderCreation, OrderFulfillment, OrderTracking). Теперь работа могла быть parallelized.

Challenge 2: Database per service pattern сложнее, чем ожидалось

Раньше, если нужна информация из разных domains, один SQL JOIN.

Сейчас:

• Order Service нужна информация из Inventory Service
• Два option:
  • Sync call (медленнее, blocking)
  • Async call (быстрее, но сложнее для consistency)

Решение: Использовали saga pattern для distributed transactions. Это сложно, но работает.

Challenge 3: Deployment coordination

Теперь 10 services, каждый может deploy independently. Но если Order Service и Payment Service должны work together с новым API, нужна coordination.

Решение: API versioning. Несколько версий API могут co-exist. Олдер clients используют V1, новых V2. Постепенно migrate.

Challenge 4: Team complexity

Раньше: 1 product, 1 team, 1 prioritization. Теперь: 1 product, 10 teams, разные prioritization.

Что если Order Squad хочет feature, которая требует изменение в Payment Squad API? Зависимость между teams.

Решение: Strong PM alignment. Еженедельные syncs, shared OKRs. Если Squad A блокирует Squad B, это эскалируется и решается быстро.

Результаты (после 18 месяцев)

Success metrics:

1. Development speed:

   • До: фича требует 8-12 недель
   • После: фича требует 2-4 недели
   • 4x улучшение

2. Deployment frequency:

   • До: deploy раз в 2 недели (рискованно)
   • После: каждый squad может deploy несколько раз в день
   • Более частые, меньшие changes = меньше риск

3. Scaling:

   • До: нельзя нанять новую team (всё связано)
   • После: new feature можно own отдельной team

4. Reliability:

   • До: если одна часть system down, весь сервис down
   • После: если Payment Service down, Order Service still works
   • Более resilient system

5. Technology variety:

   • До: только Python/Django
   • После: Order Service на Python, Payment Service на Go (faster), Notification на Node.js
   • Каждый team выбирает best tool для своего use case

Lessons learned

1. Complexity растёт экспоненциально Микросервисы не решают complexity, они меняют shape of complexity. Вместо одного big problem, много smaller problems, но нужна coordination.

2. People > Technology Технический challenge это просто половина. Другая половина это организовать людей. Нужна strong PM leadership, shared vision, alignment.

3. Strangler Fig pattern это key Миграция старого системы на новую одновременно с development новых фич это HARD. Strangler Fig pattern позволяет делать это.

4. Planning это critical Этот проект требовал 3 месяца planning, прежде чем писать одну строчку кода. Это себя оправдало потому что execution был smooth.

5. Communication is everything С 10 teams, coordination это biggest challenge. Потратить time на правильные communication channels это investment в успех.

6. Accept technical debt incremental Нельзя перестроить всё идеально в день. Нужно accept, что есть technical debt. Планировать cleanup iteratively.

Почему это important для интервью

Этот проект показывает:

• Я может справиться со сложностью
• Я может лидировать big initiatives
• Я может coordinate multiple teams
• Я может balance speed with quality
• Я может take calculated risks
• Я может learn новые технологии
• Я может manage deadline и scope

Это не просто technical problem. Это organizational change problem, которое требует PM leadership.