You migrate customers, not systems
Replacing a system that cannot pause costs reconciliation, not downtime.
Can you switch off the system that takes the money? You can, and operators do: pick the quiet hour at the end of a cycle, freeze rating, move the balances, bring the new one up. Anyone who has run that night will say so before you finish proposing anything else.
What the window does not do is stop the usage. Subscribers keep placing calls and consuming data while the rater is down, and the host network keeps counting all of it whether or not anything of ours is listening. So the freeze does not remove the reconciliation. It concentrates it. Every event on either side of that boundary is still rated exactly once, by one system or the other, and the two must agree about which one owned it.
The cost of replacing a system that takes money is therefore not downtime. It is reconciliation. Downtime is the part you notice, which is why it is what everybody plans around, and it is the cheaper of the two.
The smallest thing you can move is a customer
If reconciliation is the cost, what can be reconciled in pieces?
Not components. Splitting a rating pipeline halfway leaves a single event whose price depends on both systems, and proving that two implementations agree about one event is harder work than running either of them. The seam has to fall somewhere no event crosses it.
A customer is such a seam. All the usage belonging to one customer can be assigned wholly to one system, which turns “who rated this” into a lookup and not an argument. Our consumers are named companies, each selling mobile service under its own brand, so that seam is already drawn in the commercial arrangement before anyone opens a diagram.
It is what makes a migration incremental and not a bet. One customer moves, the others do not, and the reconciliation you owe is bounded by that customer’s traffic and not by all of it. A cutover is the same work with everyone in it at once, on one night, with no version of the evening in which you stop.
Which makes separability a migration decision, not an efficiency one
Each brand on our platform runs on its own infrastructure instead of as a flag inside one shared installation.
As steady-state design that is hard to defend. One installation serving everyone is cheaper to run, cheaper to watch and cheaper to reason about, and tenancy as a column is the obvious road there. Most of the time the obvious road is the correct one.
It stops being correct the moment two truths must hold at once. Tenancy as a flag optimises the steady state; tenancy as a boundary buys the option to move one customer at a time. A shared installation cannot put half its tenants on a different charging system, because the installation is the thing being replaced. A boundary lets one brand sit on the new system while the others stay where they are, and neither side needs to know about the other.
None of that requires services over a monolith. A monolith with a hard boundary per customer has the option; a fleet of services sharing one rating database does not. Separability is the property that counts, and it is not the same as being made of small pieces, though the two arrive together often enough to get confused.
Where the trade stops paying
Separability costs about what you would expect, and the bill lands before the benefit does:
- more to deploy, patch, watch and keep in step;
- a change that must reach everyone gets slower, not faster;
- consistency across customers becomes something you maintain instead of something the database gives you.
The shared installation is the better design whenever no platform change is coming. Paying for separability in that world is waste, and calling it future-proofing does not convert it into leverage.
So the bet is on whether you will change platforms again, and it gets placed when you know least about that. What tilts it here is that the events cannot be replayed and the businesses selling on top of us cannot be asked to wait. Almost everywhere else work can pause — which is why the boundary reads as over-engineering to anyone who has never had to prove that two systems agreed about one phone call.