Наш продукт работает на устаревшем PHP-монолите: всё — вход пользователей, платежи, каталог, рассылки и отчётность — собрано в одном проекте и одной базе. С ростом трафика это стало узким местом. Масштабировать нечего по отдельности, а деплой превратился в лотерею: правишь одну строчку в отчётах — выкатываешь весь монолит и молишься, чтобы не задеть оплату. Один тяжёлый запрос способен положить половину функций сразу. Полное переписывание с чистого листа мы не рассматриваем — это долго, дорого и слишком рискованно для живого бизнеса. Нужна инженерная, пошаговая эволюция.
Ждём от исполнителя прежде всего трезвого анализа, а не гонки за модными словами. Сначала разбираемся в текущей логике, находим границы ответственности (bounded contexts) и вместе решаем, какой блок дешевле и безопаснее отделить первым. Каждый выделенный сервис прячется за собственным контрактом API, а переключение идёт через флаг, чтобы в любой момент можно было откатиться на монолит. Отдельно нужна брокерная очередь сообщений: тяжёлые и пиковые операции должны уходить в фон и не тормозить ответ пользователю. И контейнеры — чтобы каждый сервис собирался, проверялся и катился независимо.
Планируем не рывком, а этапами. Первый шаг — вынести один некритичный контекст, погонять его рядом с монолитом под реальной нагрузкой, снять метрики и лишь затем идти дальше. Ценим прозрачные объяснения и честные оценки рисков.
Что входит в первый этап:
— Разобрать модули и выбрать первый контекст под вынос.
— Описать контракт API и подключить его через переключатель.
— Поднять очередь сообщений для одного фонового сценария.
— Упаковать сервис в контейнер с повторяемой сборкой.
Ждём от исполнителя прежде всего трезвого анализа, а не гонки за модными словами. Сначала разбираемся в текущей логике, находим границы ответственности (bounded contexts) и вместе решаем, какой блок дешевле и безопаснее отделить первым. Каждый выделенный сервис прячется за собственным контрактом API, а переключение идёт через флаг, чтобы в любой момент можно было откатиться на монолит. Отдельно нужна брокерная очередь сообщений: тяжёлые и пиковые операции должны уходить в фон и не тормозить ответ пользователю. И контейнеры — чтобы каждый сервис собирался, проверялся и катился независимо.
Планируем не рывком, а этапами. Первый шаг — вынести один некритичный контекст, погонять его рядом с монолитом под реальной нагрузкой, снять метрики и лишь затем идти дальше. Ценим прозрачные объяснения и честные оценки рисков.
Что входит в первый этап:
— Разобрать модули и выбрать первый контекст под вынос.
— Описать контракт API и подключить его через переключатель.
— Поднять очередь сообщений для одного фонового сценария.
— Упаковать сервис в контейнер с повторяемой сборкой.
