Strangler Fig & Seams — Find the Bug¶

Category: Anti-Patterns at Scale → Strangler Fig & Seams Covers (collectively): Strangler Fig pattern · Seams · Branch by Abstraction · Characterization tests · Parallel-run / shadow & verification

This file is critical-reading practice. Each snippet below is a plausible attempt at incremental replacement — code or a plan that looks like a textbook strangler migration but contains a flaw that defeats its own safety guarantees. Your job is to read it the way a careful reviewer does and answer three questions:

What's wrong with this migration step? What concrete failure does it cause? How would you fix it?

The "bug" here is rarely a crash on line one — it's a flaw in the technique that silently removes the safety net the strangler is supposed to provide: a parallel run that can't actually catch divergence, a "characterization" test that doesn't characterize, an abstraction that doesn't decouple, a cutover with no way back.

How to use this file: read each snippet and write your own answer before expanding the collapsible. The skill you're training is noticing where the safety guarantee leaks, not recalling a name.

Table of Contents¶

1. The shared-state branch by abstraction
2. The characterization test that asserts the ideal
3. The leaky abstraction
4. The routing layer with no way back
5. The cutover that deletes too early
6. The shadow that charges twice
7. The comparison that always agrees

Snippet 1 — The shared-state branch by abstraction¶

// Go — branching the pricing engine by abstraction. Old and new behind one interface.
type Pricer interface {
    Price(cart *Cart) Money
}

// A shared accumulator the engine uses while pricing.
type engineState struct {
    runningTotal Money
    lineCount    int
}

var state = &engineState{} // shared by BOTH implementations

type legacyPricer struct{}

func (legacyPricer) Price(cart *Cart) Money {
    state.lineCount = len(cart.Items)
    for _, it := range cart.Items {
        state.runningTotal += it.Price * Money(it.Qty)
    }
    return state.runningTotal
}

type newPricer struct{}

func (newPricer) Price(cart *Cart) Money {
    state.runningTotal = 0 // "reset" before computing
    for _, it := range cart.Items {
        state.runningTotal += discounted(it)
    }
    return state.runningTotal
}

What's wrong with this migration step? What concrete failure does it cause? How would you fix it?

func (legacyPricer) Price(cart *Cart) Money {
    var total Money
    for _, it := range cart.Items {
        total += it.Price * Money(it.Qty)
    }
    return total
}

func (newPricer) Price(cart *Cart) Money {
    var total Money
    for _, it := range cart.Items {
        total += discounted(it)
    }
    return total
}

Snippet 2 — The characterization test that asserts the ideal¶

# Python — "characterization" test written before replacing legacy tax logic.
def legacy_tax(amount, region):
    # legacy: EU is 20%, US is 8%, and (quirk) "food" region is hard-coded 0%,
    # AND a known bug: negative amounts are taxed as if positive.
    if region == "food":
        return 0.0
    rate = 0.20 if region == "EU" else 0.08
    return abs(amount) * rate          # the abs() is the legacy bug

def test_characterize_legacy_tax():
    # "Pinning" the behavior before we migrate.
    assert legacy_tax(100, "US") == 8.0
    assert legacy_tax(100, "EU") == 20.0
    assert legacy_tax(-100, "US") == -8.0   # what it SHOULD be (negative)
    assert legacy_tax(50, "food") == 0.0

What's wrong with this migration step? What concrete failure does it cause? How would you fix it?

assert legacy_tax(-100, "US") == -8.0

def test_characterize_legacy_tax():
    # Captured by RUNNING legacy_tax — bugs and quirks included.
    assert legacy_tax(100, "US") == 8.0
    assert legacy_tax(100, "EU") == 20.0
    assert legacy_tax(-100, "US") == 8.0    # the abs() bug, PINNED as-is
    assert legacy_tax(50, "food") == 0.0    # the food=0% quirk, PINNED as-is

Snippet 3 — The leaky abstraction¶

// Java — the abstraction for branch-by-abstraction over the storage layer.
public interface UserStore {
    LegacyResultSet query(String sql);   // exposes the legacy DB's own type
    LegacyConnection getConnection();     // ...and its connection type
}

class LegacyUserStore implements UserStore {
    public LegacyResultSet query(String sql) { return legacyDb.run(sql); }
    public LegacyConnection getConnection()  { return legacyDb.conn(); }
}

// callers:
LegacyResultSet rs = store.query("SELECT * FROM users WHERE id = " + id);
while (rs.legacyNext()) {
    User u = new User(rs.getLegacyColumn("name"), rs.getLegacyColumn("email"));
    ...
}

What's wrong with this migration step? What concrete failure does it cause? How would you fix it?

public interface UserStore {
    Optional<User> findById(long id);
    List<User> findByEmailDomain(String domain);
}

class LegacyUserStore implements UserStore {
    public Optional<User> findById(long id) {
        // legacy ResultSet handling stays HIDDEN behind the interface
        ...
    }
}

Snippet 4 — The routing layer with no way back¶

# Python — routing between old and new order processors during cutover.
NEW_PROCESSOR_ENABLED = True   # set at process start from an env var

def process_order(order):
    if NEW_PROCESSOR_ENABLED:
        return new_processor.process(order)
    return legacy_processor.process(order)

# Deploy config:
#   ORDER_PROCESSOR_NEW=true   # flipped on for the cutover

What's wrong with this migration step? What concrete failure does it cause? How would you fix it?

def process_order(order):
    # Evaluated per call → instant rollback, gradual ramp, per-tenant targeting.
    if flags.enabled("order.use_new_processor", tenant=order.tenant_id):
        return new_processor.process(order)
    return legacy_processor.process(order)

Snippet 5 — The cutover that deletes too early¶

// Go — the cutover commit for the new shipping engine.
// PR description: "New engine is live behind the flag at 50%. Deleting the
// legacy path now to keep the codebase clean — git has the history if we
// ever need it back."

type ShipPricer interface {
    Ship(cart Cart) Money
}

// DELETED in this commit:
//   - legacyShipPricer (the old implementation)
//   - the routingShipPricer facade
//   - the "shipping.use_new" flag check
//
// After this commit, callers point straight at newShipPricer:
func NewCheckout() *Checkout {
    return &Checkout{ship: newShipPricer{}}
}

What's wrong with this migration step? What concrete failure does it cause? How would you fix it?

Snippet 6 — The shadow that charges twice¶

# Python — a "scientist"-style parallel run to verify the new payment path.
def charge_order(order):
    old_result = legacy_charge(order)   # the served result

    if sampler.should_sample():
        # Shadow the new path to compare.
        new_result = new_charge(order)  # run new alongside old
        if new_result != old_result:
            mismatch_sink.report(order, old_result, new_result)

    return old_result

def new_charge(order):
    charge_id = stripe.charge(order.card, order.total_cents)   # REAL charge
    audit_log.write(order.id, charge_id)
    return charge_id

What's wrong with this migration step? What concrete failure does it cause? How would you fix it?

def charge_order(order):
    old_result = legacy_charge(order)

    if sampler.should_sample():
        # Run new with FAKE collaborators: it computes what it WOULD do,
        # but charges nothing and writes nothing real.
        shadow = NewCharger(gateway=RecordingGateway(), audit=NoopAudit())
        intended = shadow.charge(order)          # no real charge happens
        if intended.command != old_result.command:
            mismatch_sink.report(order, old_result, intended)

    return old_result

Snippet 7 — The comparison that always agrees¶

// Go — comparing old and new during the parallel run before cutover.
type Result struct {
    Total     Money
    Breakdown []LineCharge
    ComputedAt time.Time
}

func compare(old, new Result) bool {
    // Marshal both to JSON and compare the bytes — simple and thorough.
    oldJSON, _ := json.Marshal(old)
    newJSON, _ := json.Marshal(new)
    return bytes.Equal(oldJSON, newJSON)
}

// In the shadow:
if !compare(oldResult, newResult) {
    mismatchSink.Report(oldResult, newResult)
}

What's wrong with this migration step? What concrete failure does it cause? How would you fix it?

func compare(old, new Result) bool {
    if old.Total != new.Total {
        return false
    }
    // Order-independent comparison of the breakdown; ignore ComputedAt entirely.
    return sameCharges(old.Breakdown, new.Breakdown)
}

func sameCharges(a, b []LineCharge) bool {
    if len(a) != len(b) {
        return false
    }
    sort.Slice(a, func(i, j int) bool { return a[i].SKU < a[j].SKU })
    sort.Slice(b, func(i, j int) bool { return b[i].SKU < b[j].SKU })
    return reflect.DeepEqual(a, b)
}

Summary — patterns of spotting¶

You don't catch a broken strangler by spotting a syntax error — you catch it by asking which safety guarantee just leaked. The repeatable checks from these seven snippets:

• Are the two implementations actually independent? If old and new share mutable state, you don't have a branch by abstraction — you can't run, swap, or compare them safely (Snippet 1).
• Does the "characterization" test capture actual or ideal behavior? A test asserting what the code should do can't protect a migration; it must pin what the code does, quirks and bugs included, captured by running it (Snippet 2).
• Does the abstraction leak the old implementation's types? If callers still touch legacy-shaped types through the interface, nothing is decoupled and the new implementation can't fit the hole (Snippet 3).
• Is the routing flag read per call or once at startup? A flag resolved at boot is a deploy in disguise — no instant rollback, no ramp, no targeting (Snippet 4).
• Is deletion the final step, gated on 100% + evidence? Deleting the old path or the flag mid-ramp throws away rollback exactly when it's most needed (Snippet 5).
• Does the shadow have suppressed side effects? Running a side-effecting new path "to compare" double-charges and double-writes — the most dangerous parallel-run mistake (Snippet 6).
• Does the comparator normalize nondeterminism? A comparison that always disagrees (on timestamps, ordering) destroys the signal as surely as one that always agrees (Snippet 7).

The meta-lesson: the strangler's value is entirely in its safety nets — independent implementations, behavior pinned as-is, real decoupling, instant rollback, side-effect-free verification, meaningful comparison, and finishing with deletion. Each snippet here keeps the shape of the technique while quietly cutting one of those nets. When you review a migration, don't check that the steps are present; check that each step still guarantees what it's supposed to.

Related Topics¶

• tasks.md — build the correct versions of these mechanisms from scratch.
• optimize.md — fix a parallel-run that's correct but doubles p99.
• interview.md — Q&A across the whole topic.
• senior.md — running a strangler migration across a real codebase.
• Expand-Contract Refactors — the data-evolution sibling, where coexistence bugs also hide.
• Hotspot Analysis — choosing the wrong thing to strangle is its own bug.
• Architecture → Anti-Patterns — the system-level siblings.