Extracting a service without a rewrite

Business context

A long-lived application handled onboarding, scheduling, and invoicing in one deployable. Invoicing needed a new tax treatment and a second product wanted to reuse it. Every release still required the full suite’s regression.

Technical challenge

Extract billing behind a stable contract, keep a single writer for money, and leave the rest of the monolith intact.

Constraints

• No dual-write to two ledgers.
• Feature work on scheduling continues.
• The team is small; a service mesh and twelve new repositories would be malpractice.

Approach

• Treat billing as a module with a public API inside the monolith first.
• Move persistence only after the in-process boundary was proven with contract tests.
• Publish invoice facts as events for the second product; do not let it write to billing tables.
• Keep deploy independent only when on-call and observability were ready.

Technologies in play

Named only at the category level. We do not list products as if they were a certified stack for a fictional client.

• The language and datastore already in production
• Contract tests in the existing CI
• The organisation’s current message transport, or a boring alternative if none existed

Implementation notes

• The first release changed nothing about runtime shape — only module boundaries and tests.
• A compatibility façade allowed old screens to keep working.
• The second product consumed events, then a read API, never the billing database.

Outcomes

No invented reduction in lead time. The point of the scenario is the sequence, not a vanity metric.

Lessons

• A modular monolith is a valid end state, not a failure of nerve.
• Extract the capability that has a real second consumer or a real independent risk.
• Events are facts. They are a poor substitute for a request/response when the caller needs an answer now.