New services must interact with a legacy system that cannot handle their load or their pace of change. Which integration patterns apply?

The patterns

1. Anti-corruption layer. New services must not inherit legacy data models, naming and semantics. Translation happens explicitly at the boundary, or the new architecture becomes a distributed copy of the old one — the most common way modernisation produces no benefit.

2. Materialised read store. An owned service reads from the legacy system at a rate it can tolerate and materialises the data into a store shaped for the new access pattern. New services scale their reads against that store rather than against the legacy system. This is the load-decoupling pattern and it is usually the first thing to build.

3. Change data capture where available. Reading the legacy database's replication log gives near-real-time changes with no query load on the legacy application and captures deletes — far better than polling, which adds load, misses deletes and races at the cursor boundary.

4. Buffering and rate limiting on writes. New services write into a queue; a controlled worker applies changes to the legacy system at a rate it can absorb, with retries and idempotency because the legacy system will reject or fail under concurrency.

5. A façade with routing, so requests can be directed to legacy or new implementations per capability — which is what makes incremental replacement possible.

6. Reconciliation, because in any asynchronous copy arrangement drift is a certainty and the only question is whether you detect it or a customer does.

The pattern to avoid

Direct synchronous calls from every new service to the legacy system. Each new service couples to the legacy system's availability, concurrency limits and data model, and as services multiply the load grows without bound. The first serious traffic event takes down a system that cannot be scaled.

The extreme-scale addition

Where the new services face very high traffic — a demand event, a flash sale — the legacy system must be structurally removed from the synchronous path, not merely protected. That means the read store serves all reads, writes are queued and applied asynchronously, and the legacy system's availability does not affect the customer-facing path at all.

Anything less means the legacy system's capacity is the platform's capacity, which is the constraint the modernisation exists to remove.

The strategic property

The integration service becomes the seam for eventual replacement. When the legacy system is retired, only that service changes and the new services see the same interface throughout — which is what turns replacement from a coordinated migration of everything into an internal change.