All experiments
EXPERIMENT 04 / System evolution

Strangler Fig.

Replace a system one capability at a time. Keep the business running.

HOW TO READ THIS

Change one thing at a time.
The interesting part is usually why it moved.

Interactive experiment STEP 00
Switching approach resets the experiment

Change the implementation while the system keeps serving traffic.

Strangler Fig: Direct routingClient to Existing system, 100% of traffic. All traffic goes directly to the existing system.100% of trafficCLIENTClientLive requestsSERVICEExisting system100% of traffic
clientClientLive requests→ Existing system · 100% of traffic
serviceExisting system100% of trafficReceives work
Baseline systemSynchronous requestDeterministic · step by step
Existing route100%
New route0%
Errors / 20 sampled0
Sampled requests0
Observation

All traffic goes directly to the existing system.

Each action samples 20 requests. Routing rollback assumes compatible data; it does not reverse changes already written.

THE PROBLEM

A wholesale rewrite concentrates delivery risk and delays useful feedback until the final cutover.

A routing boundary gradually moves a compatible capability to a replacement. The lab simplifies that migration into traffic percentages.

EVERY DECISION HAS A COST

What this buys, and what it charges you for.

Context, not a scorecard
Without the patternWith the patternILLUSTRATIVE / 0–100
EvolvabilityHigher is preferable
58+

Capabilities can move in small, observable increments.

DeployabilityHigher is preferable
48+

Traffic routing creates a controlled release and rollback boundary.

Operational complexityLower is preferable
41+

Both implementations and their integration must run during transition.

Infrastructure costLower is preferable
36+

Temporary duplication increases the relative footprint until retirement.

Illustrative scores for this scenario, on a 0–100 scale. They express a direction of change, not a benchmark. Your constraints can change the result. Select a quality to explore the reasoning.

+ What improves

  • Release and validate a small migration slice.
  • Keep a rollback route while the old implementation remains compatible.

± What gets harder

  • Two implementations coexist during migration.
  • Shared data and divergent behavior complicate rollback.
  • Routing, translation and dual reads are scaffolding: real work that you build deliberately and then delete.
GO A LAYER DEEPER

Where the edges are.

A pattern is only useful once you know where it stops working. These are the boundaries worth knowing before you commit to it.

When it earns its place
  • A live system has interceptable boundaries and separable capabilities.
When to leave it out
  • The system is small enough to replace safely in one release.
New ways to fail
  • The routing facade becomes a bottleneck.
  • Dual writes drift; the migration stalls indefinitely.
Operating the pattern
  • Compare responses and errors by route; define a retirement milestone.
The people behind the system
  • Assign ownership of the old system through its actual removal.
Other directions to consider
  • Refactor in place
  • Branch by abstraction
  • A coordinated replacement