Breaking up a monolith and giving reporting back to the business

Context

A single application had accumulated everything: the customer-facing API, background processing, admin tooling, and reporting, all sharing one database and one deploy.

That design is efficient early and expensive later. By the time we were involved, a reporting query could slow the customer-facing API, deploys were risky because everything shipped together, and every new business question became an engineering ticket. The analytics backlog was measured in weeks.

Client name withheld by agreement.

The constraints

No big-bang cutover. The system was in continuous use. Whatever we did had to be incremental and reversible.

The reporting problem was urgent. Engineering time spent writing one-off queries was the most visible cost, and relieving it early bought goodwill for the longer migration.

Cost mattered. The database had been scaled vertically for years because that was the only lever available. It was the single largest infrastructure line item.

What we changed

Separating read from write

The first move was not the microservice split — it was getting analytical load off the transactional database.

We built ETL pipelines into a cloud data warehouse, so reporting queried a system designed for scanning large volumes rather than one tuned for row-level transactions. This immediately removed the class of incident where a heavy report degraded customer-facing performance.

Query performance on analytical workloads improved roughly 20×, largely because a columnar warehouse is simply the right tool for that job.

Strangling the monolith

Rather than rewriting, we extracted services incrementally. New functionality was built outside the monolith. Existing high-traffic paths were moved out one at a time, with the monolith proxying to the new service until traffic was fully shifted and the old code could be deleted.

Each extraction was independently deployable and independently revertible. Nothing required a coordinated cutover.

As services came out, they could be scaled according to their own load profile instead of inheriting the monolith’s worst case. Combined with removing analytical load, that let the central database be right-sized — the main driver of the 60% infrastructure reduction.

Self-service reporting

The warehouse solved the technical problem. It did not, by itself, solve the organizational one: people still had to ask an engineer.

We modeled the warehouse around business concepts rather than mirroring application tables, and built dashboards over that model for the recurring questions. Well-defined metrics, documented, updating automatically.

The result was that most routine questions stopped reaching engineering at all, and the ones that did were genuinely novel.

Architecture

Client traffic reaches an API layer that routes to individual services, each owning its data and scaled independently. Transactional data lives in Postgres. ETL pipelines move data on a schedule into BigQuery, where a modeled layer exposes business concepts to dashboards and analysts. Infrastructure is defined as code so environments are reproducible.

Results

API latency fell by about 95%, mostly from removing analytical contention and right-sizing services to their actual traffic. Analytical query performance improved roughly 20×. Infrastructure cost dropped about 60%.

The organizational change outlasted the technical one: reporting stopped being an engineering dependency.

What we would tell you before starting something similar

Move analytics off your transactional database first. It is the smallest change with the largest immediate effect, and it buys time for everything else.

Strangle, do not rewrite. Incremental extraction is slower on paper and dramatically more likely to finish. Rewrites tend to be abandoned somewhere in the middle, leaving two systems to maintain.

A warehouse alone does not fix reporting. If the data model mirrors your application tables, people still need an engineer to interpret it. The modeling layer is what actually makes it self-service.