Monolith to Services Refactoring

Signs the monolith is holding you back, and signs it is not

A monolith is not a problem by itself. Plenty of successful products run on one well organized codebase and one database. Tepia looks for specific symptoms before recommending any split:

• A release needs the whole team to freeze work for days, so fixes wait for the next window.
• One heavy report or export slows checkout or job booking for every user.
• A third party outage, such as a slow ERP or CRM sync, ties up web requests and takes the app down with it.
• Two teams keep breaking each other’s features because the code has no internal boundaries.
• One part of the system needs to scale far beyond the rest, for example notifications during a seasonal peak.

If the real issues are missing tests, tangled code and an outdated framework, splitting into services will spread those problems across a network. In that case Tepia usually recommends a modular monolith first, or a broader look at whether to rebuild or refactor.

Choosing what to extract first

The first extraction should be valuable, loosely coupled and low risk. Tepia scores candidate modules with the client, and the result often looks like this:

Notice the core domain sits at the bottom. Tepia extracts the edges first, where boundaries are already clear, and earns confidence before touching the logic the business depends on most.

The strangler fig pattern in practice

Martin Fowler named the strangler fig pattern after a vine that grows around a tree until it can stand on its own. Tepia applies it in a repeatable sequence for each module:

1. Place a routing layer, such as an API gateway or reverse proxy, in front of the monolith so traffic can be redirected without client changes.
2. Create a seam inside the monolith by moving the module behind an internal interface and removing direct database access from other code.
3. Build the new service with its own data store, and keep data in step through events or change data capture during the transition.
4. Run the service in shadow mode, comparing its results with the monolith’s on real traffic.
5. Shift traffic gradually with feature flags while watching error rates and latency.
6. Delete the old code path once the service has handled full traffic for an agreed period.

Because each module goes through these steps on its own, the business can pause between extractions to ship features. Tepia also uses this pattern for legacy system modernization when the old system cannot be refactored in place.

For companies whose main pain is connecting business systems, integrations are often the best place to start. Pulling QuickBooks, Salesforce and ERP sync code out of the request path into its own service, fed by a queue, means a partner outage slows a background job instead of every user’s screen, and Tepia can add new connections without redeploying the core application.

Data, testing and operations once you run services

The most common failure in service projects is keeping one shared database. Services that read each other’s tables cannot be changed or deployed independently, so Tepia gives each service ownership of its data and shares changes through events, using the patterns on our event driven integration page. Reports that need data from several services read from a replica or a reporting store instead.

Operations change too. Each service gets its own pipeline with automated tests and contract tests that catch breaking API changes before deploy, as described on our DevOps and CI/CD page. Services usually run as containers on Amazon ECS, Azure Container Apps or Google Cloud Run, with centralized logs, OpenTelemetry tracing and alerts per service. Tepia keeps the number of services small, since every service is one more thing to deploy, monitor and secure.

Tepia agrees on success measures before the first extraction, usually the four DORA delivery metrics plus a business number such as checkout latency or failed syncs per week. Those are recorded for the monolith at the start, so after each cutover you can see whether deploys became more frequent, failures less common and recovery faster. If a module’s numbers do not improve, that is a signal to stop extracting and invest elsewhere.

How Tepia approaches monolith refactoring

1. Discovery: code and dependency analysis, database access mapping, a review of deployment history and interviews with engineers and product owners. Deliverables are an Investigation Summary, an Interview Summary and User Stories framed as outcomes, such as releasing notification logic without a full deploy.
2. Design: a target architecture, service boundary diagrams, an extraction order, and wireframes for any admin or monitoring screens, supported by a design questionnaire and style guide for those internal tools.
3. Development and Testing: an Alpha extraction of the first module in staging and a Beta in shadow mode on production traffic, with functional, contract, load and user acceptance test plans.
4. Training: working sessions with your engineers on the new pipelines, tracing tools and runbooks so they can own the services.
5. Launch: data migration into the new service’s store, a gradual traffic shift, and removal of the old code path.
6. Support: issue resolution, bug tracking, incident response and feature requests while the next module is planned.

Typically Discovery takes 1 to 3 months, development and QA 2 to 6 months per stage, and each cutover about a month. Read about our process or talk to Tepia about your codebase.

Frequently asked questions