Wealth Domain Modeling in Legacy Systems Through Incremental Extraction Using the Strangler Fig Pattern

The Legacy System Challenge and the Urgency of Modernization

Many companies operate on older software that has accumulated complexity over decades. This type of system, known as a legacy monolith, functions like a giant gear where any minor change can break critical functionality without warning. In practice, this means the engineering team spends more time trying to understand old code than building new solutions for the market.

When the business deals with the wealth domain—the set of financial rules, interest calculations, and monetary transactions that generate real revenue—the risk of failure is unacceptable. Trying to rewrite the entire system at once is usually a fatal mistake leading to budget overruns and endless delays. Modern engineering needs approaches that allow architecture to evolve safely, continuously, and in a controlled manner.

Understanding the Strangler Fig Pattern in Practice

The Strangler Fig pattern, inspired by a fig tree that envelops its host tree until it replaces it, proposes replacing the old system in parts. Instead of shutting down the monolith all at once, we build a new application alongside it and gradually redirect specific functionalities. In practice, the user keeps accessing the same address, but the intelligent system behind the route decides whether the request goes to the old code or the new code.

This method protects the business against service interruptions and allows the team to deliver business value quickly. Each small migrated functionality reduces dependence on the old database and shrinks the risk surface. Over time, the old part of the system shrinks and is discarded cleanly, without drama or prolonged downtime in daily operations.

Isolating the Wealth Domain with Surgical Precision

The wealth domain requires extra attention because it involves the company's most sensitive money and contractual rules. When applying incremental extraction, the first step is mapping the boundaries of this domain within the monolith, identifying which tables and routines calculate financial values. In practice, this works like performing precision surgery to separate vital organs without interrupting the patient's blood flow.

We isolate these rules into a modern service designed with clean architecture and rigorous automated tests. This new component takes exclusive responsibility for wealth calculation, ensuring that any regulatory or tax change is implemented in minutes rather than requiring weeks of adjustments in the old monolith.

Traffic Orchestration and Intelligent Routing

To ensure replacement occurs without the customer noticing, we use an edge component, such as a reverse proxy or an API Gateway, which acts as the conductor of the orchestra. This component analyzes each incoming request and decides which system should handle it. In practice, if a customer checks their statement balance, the request might still go to the old system; but if they perform a new financial operation, the route is directed to the modern microservice.

This strategy allows low-risk production testing. We can send just a small percentage of traffic to the new application, monitoring performance and errors in real-time. If anything goes wrong, routing instantly reverts to the monolith, ensuring continuous operational stability.

{
  "route": "/api/v2/wealth",
  "strategy": "weighted",
  "targets": [
    { "host": "legacy-monolith.internal", "weight": 80 },
    { "host": "wealth-service.internal", "weight": 20 }
  ]
}

The configuration snippet above illustrates how the load balancer splits traffic between the legacy system and the new wealth service. This percentage division is the key to validating the stability of the new code under real production load.

Data Synchronization and Eventual Consistency

One of the biggest challenges in incremental migration is keeping data synchronized between the old and new databases. Since the monolith still operates in parallel, it continues writing information to legacy tables. In practice, we must implement replication mechanisms or messaging events to ensure the new service receives updated copies of this information in real time.

We use eventual consistency patterns, where synchronization occurs within milliseconds of the original write. If divergences occur, automated audit routines verify and correct records. This care prevents users from perceiving financial inconsistencies during the transition period between architectures.

Final Considerations and Next Steps

Adopting the Strangler Fig pattern to isolate the wealth domain in legacy systems turns an extreme risk project into a controlled evolution. The key to success lies in the disciplined patience of migrating small functional slices and validating each delivery with rigorous business and technology metrics. By turning large rewrites into continuous incremental improvements, engineering delivers constant value without compromising the company's operational stability.

Modernizing legacy does not mean updating technologies just for the sake of it, but returning the agility necessary for the business to compete in the market. With a clear strategy for routing, data synchronization, and critical rule isolation, any organization can overcome the weight of technological the past and build a sustainable future.