A Telecom Operator Wanted to Break Apart Its Billing Platform. We Recommended Against It
CLIENT
A mid-sized US telecom operator providing voice, data, and managed network services to enterprise and wholesale customers. The company managed several million active subscriber accounts and ran a billing and operations support platform built incrementally over roughly twelve years. The engineering and platform team had around 120 people.
CHALLENGE
The billing platform handled rating, invoicing, payment collection, dispute management, and regulatory reporting across multiple service lines, all in a single tightly coupled codebase extended repeatedly without a clear architecture.
New product features were slow to ship. Changes to the rating engine routinely broke invoice generation. The team had documented at least four incidents the previous year where a fix in one part of the platform caused an undetected error elsewhere, only surfacing during a billing cycle.
The CTO wanted the platform broken into microservices: independent services, independent deployments, teams that could work without coordinating every change. They brought us in to lead the decomposition.
SOLUTION
Before accepting the scope, we asked to spend three weeks with the engineering team running a platform assessment. We had done earlier work with this client on a network inventory data quality project and already understood how their systems connected.
The core problem was different from what a microservices decomposition would fix. The platform’s modules were coupled at the data layer, not the service layer. The rating engine, invoice generation, and dispute management all wrote to and read from the same database tables, often without documentation. Breaking these into separate services would move the coupling from in-process function calls to cross-service database dependencies, which are harder to manage and debug, not easier.
A team of 120 people managing a distributed billing system across a dozen services would also face operational overhead their current structure wasn’t built for. Billing platforms run under strict SLA requirements and regulatory reporting deadlines. A partially decomposed distributed system, mid-migration, carries real risk in that environment.
We brought this analysis to the CTO and VP of Engineering. The recommendation was a modular restructure within the existing deployment model: strict module boundaries, no shared database access, clear internal APIs between modules, and a deployment pipeline allowing modules to test independently.
The work ran across four phases: mapping every cross-module database dependency; enforcing module data ownership, giving each module sole write access to its own tables and replacing cross-module reads with internal API calls; rebuilding the deployment pipeline around the new structure; and documentation and handover, with every module assigned an owner, a runbook, and a defined interface.
RESULT
The restructure completed in twenty-two weeks.
In the first full billing cycle after completion, the team reported zero cross-module incidents — the first time in over a year. The pattern of a fix in one area surfacing a problem somewhere else had stopped.
Deployment frequency increased from roughly monthly to bi-weekly. The compliance reporting team noted that their monthly regulatory reports, which had previously required manual cross-checks after each run, now matched automatically. The data ownership changes had eliminated the inconsistencies causing the discrepancies.
Six months later, the CTO said that the microservices direction would have made the coupling problem harder to find and harder to fix. The modular structure also gave them a cleaner path to extract individual modules as separate services in the future, if the team and scale ever warranted it.
TECHNOLOGY STACK
- Java + Spring Framework — billing platform restructured around module boundaries with defined internal APIs
- Oracle DB — consolidated data ownership per module with access controls enforced at schema level
- Apache Kafka — event bus for cross-module communication replacing direct database reads
- Jenkins + ArgoCD — CI/CD pipeline with per-module test stages and independent validation before release
- Prometheus + Grafana — module-level performance monitoring and billing cycle observability
- SonarQube — code quality and dependency analysis integrated into the PR process
- Confluence — module ownership documentation and runbooks maintained by the internal team
When a legacy platform becomes difficult to scale, microservices are often the first solution that comes to mind. But don’t jump to conclusions – in many systems, the real coupling sits in the database layer, not the application layer. Breaking the platform apart too early simply moves the complexity into a distributed environment.
Before committing to a costly migration, make sure you understand the dependency structure you’re actually dealing with. Need an alternative perspective? See how REW Technology can help.
Share:
