When the application that made your success slows down every new idea, it is time to rethink it. We move monoliths to service-based architectures without interrupting the business, with modern tools and infrastructure on AWS.
Signs it is time to migrate
A monolith is not a flaw in itself. It becomes a brake when a minor change forces a full retest, when a release is prepared like a military operation, when the home page collapses because the payment module is saturated.
The same symptoms come back almost every time: deployments become rare and risky, the load of one module slows everything else, and new developers need weeks before they dare touch the code.
The opposite mistake is just as costly: splitting too early means more network, more monitoring, more things to deploy. So we start by measuring, and we only separate what justifies it.
From monolith to services
On the left, a single application: catalogue, basket, payment and search share the same code and the same database. On the right, the same application split up. A gateway receives requests and routes them to independent services, each with its own database.
A service can then be updated, replicated or replaced without touching the others.
Migrating without stopping the site
Put a gateway in front
A single entry point receives all traffic. At first it sends everything to the old system, which changes nothing for visitors.
Extract one domain at a time
We pick the most useful piece to isolate, often search or payment, rebuild it as a service, then plug it in behind the gateway.
Run both, compare, switch
Old and new run side by side. We compare results, then move traffic over in stages, with a way back at every step.
Remove the old code
Once a domain is stable, its old version disappears. The monolith shrinks until it has no reason left to exist.
Holding the load
An architecture made of services only holds the load if it is equipped for it: a cache in front of the most requested pages and queries, message queues to absorb peaks (a private sale, a mass mailing) without blocking the user, and monitoring that shows which service is struggling before customers write in.
We set up these building blocks on AWS, and we size the infrastructure from measurements rather than hunches.
Technologies
Technologies do not make the project: they serve a need. We start from what the application must do and withstand, then pick the tool that meets it at the best cost, favouring building blocks that are well known, documented and easy to hire for.
Here is our toolbox, with the situation in which we choose each tool.
Hover or tap a name to read the detail.
Cloud and architecture
Interfaces
Server
Data
Content and e-commerce
Applied AI
Where AI belongs
We bring in AI when it solves a precise problem: a search that understands the question rather than the words, an assistant that sorts incoming requests, a repetitive input task that can be automated.
We advise against it when a simple rule would do better, or when a mistake would be costly and nobody would review the output. The test we apply: if you remove the AI, what gets worse, and by how much?
An example: 41watch
41watch sells Swiss collector watches. Its site ran on PrestaShop. We moved it to a microservices environment.
The shop stayed open throughout the migration. The project took one year, on Next.js, Strapi and AWS.
Is your application showing its limits?