Freelance › Projects › Software development › Incremental decomposition of a legacy PHP monolith into microservices
Incremental decomposition of a legacy PHP monolith into microservices
Employer
Web
Project parameters
Type of cooperationOne-time project
SectionSoftware development
Prepaymentwithout prepayment
Payment methodsCash, Bank transfer
Acceptance of requestsfrom today, 05:37 until Sep 24, 2026
Project description
We run a legacy PHP application that grew over the years into a single large monolith. It handles authentication, billing, catalog, notifications and reporting inside one codebase and one database. The system has become hard to scale under load and painful to deploy: any small change forces us to redeploy everything, and one slow query can drag down features that are otherwise unrelated. We are not looking for a risky big-bang rewrite. We want a careful, incremental migration that keeps the product running and generating revenue at every step.
The core of the work is analysis before code. We expect you to map the existing behaviour, identify clear bounded contexts, and agree with us which module is the safest first candidate to extract. Each service should live behind a well-defined API contract, and the boundary should be introduced gradually so we can roll back if something misbehaves. We also want an asynchronous message queue so that slow or bursty work stops blocking user-facing requests, and containers so that a service can be built, tested and deployed on its own.
Please propose a staged roadmap rather than a single leap. A realistic plan for us starts by carving out one low-risk context, running it in parallel with the monolith, measuring the result, and only then moving on. Communication in clear English and honest trade-offs matter to us more than buzzwords.
Scope for the first stage:
— Document current modules and pick the first bounded context to extract.
— Define the API contract and wire it into the monolith behind a toggle.
— Introduce a message queue for one asynchronous workflow.
— Containerize the extracted service with a repeatable build.
The core of the work is analysis before code. We expect you to map the existing behaviour, identify clear bounded contexts, and agree with us which module is the safest first candidate to extract. Each service should live behind a well-defined API contract, and the boundary should be introduced gradually so we can roll back if something misbehaves. We also want an asynchronous message queue so that slow or bursty work stops blocking user-facing requests, and containers so that a service can be built, tested and deployed on its own.
Please propose a staged roadmap rather than a single leap. A realistic plan for us starts by carving out one low-risk context, running it in parallel with the monolith, measuring the result, and only then moving on. Communication in clear English and honest trade-offs matter to us more than buzzwords.
Scope for the first stage:
— Document current modules and pick the first bounded context to extract.
— Define the API contract and wire it into the monolith behind a toggle.
— Introduce a message queue for one asynchronous workflow.
— Containerize the extracted service with a repeatable build.
