monolith split
Monolith to microservices: first service live by day 20
Four hundred tables in one schema, and a release train that leaves once a quarter because nobody can deploy one part alone. Engineers with 25+ years in production split it: first service live by day 20, the rest by day 30.
Send the repo size and release cadence today. In 48 hours you know where the seams are and what it costs.
One repository, one schema, one quarterly release, and imports that go in circles.
- one deployable11 years of commits
- shared schema400+ tables
- release trainquarterly
- circular importscycles
First service by day 20, the split finished by day 30
Services with their own schemas and pipelines, a small shared library, deploys whenever a team is ready.
- billingGo · own schema
- catalogueGo · own schema
- shared kernellibrary
- deploysper service
The schema splits first, then the code moves
- 01days 1–4
Find the seams in the data
Query logs show which tables are read together in the same request. That is where the boundaries are, whatever the package structure claims.
- 02days 3–9
Split the schema first
Tables separate and cross-boundary joins go while everything is still one deployable. Most of the risk lives in this step, and here it is still reversible.
- 03days 8–20
Extract the first service
We take the one with the fewest inbound dependencies, which is rarely the one that annoys people most. It runs in production behind the same interface by day 20.
- 04days 18–30
Its own pipeline, then the next
The service gets its own repository, deploy and on-call rota. The next ones follow faster on the same method, and from day 30 your teams release without waiting for a train.
The platform measures, engineers choose the cut
Mapping table co-access and module coupling
Platform
From query logs and the call graph, over a period long enough to include month-end.
Proposing the seams
Both
The platform ranks candidates. An engineer checks each one against your team boundaries.
Breaking the cross-boundary joins
Platform
Mechanical work, reviewed as pull requests, shipped in small pieces your team can follow.
Choosing which service goes first
Engineer
Team ownership decides this more often than the code does.
Transaction boundaries
Engineer
Where one transaction used to cross the seam, we decide what happens on failure and write it down.
Pipelines, deploys and on-call
Both
We build each pipeline and rota with your team, so they run the services from the first deploy.
A seam is right when most changes after the split touch one side only. We measure that before we call the job done.
The people who cut the seam
Our engineers have been shipping production code for more than 25 years, and they are the best people you can put on this split. Rails, Django, Spring, .NET, Node, PHP and Go monoliths, schemas with four hundred tables and a decade of cross-boundary joins: dozens of migrations. The seam is never where the architecture diagram puts it, and they find the real one.
Fixed price before we cut, and the day the first service deploys on its own goes into the contract. A service that does not match the monolith on your traffic is not accepted.
What engineering leads ask before a split
How many services should we end up with?
As many as you have teams to own them, which is fewer than the architecture deck shows. We extract the first, run it in production, and the data shows where the next cut goes. Send the repo today and get the seam map with a price in 48 hours.
Do we have to rewrite in Go?
Only where it pays. Extraction and rewriting are separate decisions, and plenty of services stay in their original language. Where the monolith burns memory on Java or Python, a Go rewrite cuts the instance bill on the same schedule. Tell us which modules cost the most to run.
Can we keep shipping features during the split?
Yes. The step we protect is the schema separation, days 3–9, and we plan your release calendar around it with you. Everything else moves while your team ships. Send your release cadence and we fit the plan to it.
What about the shared database everyone warns about?
That is why the schema splits first. Two services on one schema are a distributed monolith that fails in worse ways than what you started with, and we never ship one. Get a quote and see the schema plan before any code moves.
What happens to shared code?
It becomes a versioned library with a small surface. If that library grows every sprint, the seam is in the wrong place, and we move it during the project while it is still cheap. Send the repo and we point to the seams in 48 hours.
Get your first service out
Give us the repo size, the release cadence and what is forcing the change. In 48 hours you have the seams, a fixed price and a date. By day 20 the first service deploys on its own.
An engineer with 25+ years in production reads the form. The first question is about your release cadence.