Поетапна декомпозиція legacy-моноліту на PHP у мікросервіси

У нас є великий legacy-застосунок на PHP, який за роки перетворився на єдиний моноліт. У межах однієї кодової бази й однієї бази даних живуть авторизація, білінг, каталог, сповіщення та звіти. Систему стало важко масштабувати під навантаженням і болісно викочувати: будь-яка дрібна зміна змушує переразгортати все повністю, а один повільний запит тягне вниз навіть ті функції, що до нього не стосуються. Ризикове «переписування з нуля» нам не підходить. Потрібна акуратна поетапна міграція, за якої продукт далі працює і приносить гроші на кожному кроці.

Основа роботи — аналіз до коду. Ми очікуємо, що ви опишете поточну поведінку, виділите чіткі обмежені контексти й разом із нами визначите, який модуль безпечніше винести першим. Кожен сервіс має жити за зрозумілим контрактом API, а межа вводитися поступово, щоб можна було відкотитися, якщо щось піде не так. Також потрібна асинхронна черга повідомлень, щоб повільні та сплескові задачі перестали блокувати запити користувачів, і контейнери, щоб сервіс можна було збирати, тестувати й викочувати окремо.

Запропонуйте, будь ласка, поетапну дорожню карту, а не один стрибок. Реалістичний для нас план починається з виділення одного низькоризикового контексту, роботи його паралельно з монолітом, вимірювання результату й лише потім — руху далі. Чесні компроміси й зрозумілі пояснення важливіші за модні слова.

Обсяг першого етапу:
— Описати поточні модулі й обрати перший контекст для виносу.
— Задати контракт API та під'єднати його до моноліту через перемикач.
— Ввести чергу повідомлень для одного асинхронного сценарію.
— Контейнеризувати винесений сервіс із відтворюваним складанням.