Write-Ownership Boundary

Eighteen months into a migration, the new system owns customer records and the old one still owns orders. A refund credits the customer and cancels an order line. The credit commits; the cancellation is rejected because the order shipped four minutes earlier. Nothing rolls the credit back, because no transaction spans the two systems. What was a single ACID unit inside the monolith became two writes with a network between them, and nobody decided that — it fell out of a diagram that assigned ownership by entity name.

The boundary is the thing that was drawn carelessly. Placing it well is the difference between a coexistence period that is merely expensive and one that quietly manufactures data defects for as long as it runs.

Why it matters

Coexistence periods run for one to three years on any real core-system replacement, and during that whole time both systems are live. Two writers for one piece of state is the failure that has no good recovery: last-write-wins silently discards a real change, and merge logic is a distributed consistency problem that nobody scoped.

The damage is also slow and invisible. Cross-boundary divergences are a minority of traffic — at roughly 1% of orders needing a refund, and a few percent of those racing a fulfilment event, a platform at 50,000 orders a day produces a handful of broken pairs a day. That is enough for a permanent finance ticket queue and far too few to move a percentage-based error alert. The first place the two facts meet is a monthly reconciliation, where the error appears as an unexplained balance rather than a list of transactions.

Implementation patterns

• Enumerate the operations that used to run inside one database transaction, and use that list to place the boundary. Do not derive it from the schema, which was never drawn to show transactions.
• One writer per entity, always, with the other side reading a replicated or API-served copy. Bidirectional write paths are the pattern with no end state.
• Accept a slower roadmap over a split transaction. Keeping the new system read-only for orders for another two quarters is cheaper than a saga that exists only because the boundary was drawn in the wrong place.
• Where a split is genuinely unavoidable, make it explicit: a saga with a named compensating action for each step, an idempotency key derived from the business event so retries are safe, and a dead-letter queue that pages on compensation failure, because a failed compensation is a correctness defect rather than a backlog item.
• Reconcile daily across the boundary on the entities that span it, alerting on the first unmatched pair rather than on a rate.
• Enforce ownership in the database, by revoking write grants rather than by documenting a rule. A rule in a wiki is violated by the first urgent production fix.

Industry example

The pattern is visible in the public write-ups of core banking and ledger migrations from 2018 onward, where the surviving programmes kept the ledger single-writer throughout and moved reads first. The archetype in the other direction: a retailer split ownership by domain name — customers new, orders old — and spent the coexistence running a monthly manual credit reconciliation, because refunds and returns both crossed the line and neither could be made atomic.

Failure scenarios

• Ownership assigned by entity name on a data-model diagram, cutting straight through the transactions the model never showed.
• Retries without idempotency keys, turning one permanent rejection into three to five duplicate compensating writes.
• Reconciliation alerting on a percentage, so a handful of broken pairs a day stays under the threshold indefinitely.
• Dual writes adopted as the boundary, which is two writers with extra steps and no authoritative side to recover from.
• The boundary moving slice by slice with no record of which entity was authoritative when, so a defect found in month 14 cannot be attributed to a system.

Trade-offs

When not to use it

Where the entities never participate in a common transaction, split ownership by entity and move on. Marketing preferences and order history do not appear in one commit, and wrapping them in a saga is machinery protecting nothing. The rule binds only on the operations that were once atomic.

It also does not apply to a cutover short enough to sit inside a change freeze. If the old system is frozen from Friday to Monday and all writes move in that window, there is no coexistence and no boundary to place. The practice exists because coexistence is long, and its cost scales with that length.

Interview question

Q: You are eighteen months into a migration. Customers are authoritative in the new system, orders in the old. Finance reports an unexplained credit balance growing month on month. Walk me through what is happening and what you change.

What a strong answer covers: identifying the cross-boundary business transaction and the absence of an atomic commit; the retry amplification and the reason a percentage alert never fired; the structural fix of moving the boundary rather than patching the handler; and, where the boundary cannot move, the saga with compensation, idempotency keys and a paging dead-letter path, plus the daily reconciliation that alerts on the first unmatched pair.

Quick check

Quiz: Why is a data-model diagram the wrong artefact for placing write ownership during coexistence? Because it shows entities rather than transactions, so a boundary drawn on it cuts through operations that were once atomic and creates split commits nobody planned.

Flashcard: Where does the write-ownership boundary belong during coexistence? Along business transaction boundaries, not entity names — one system owns each whole transaction, even if that keeps the new system read-only longer than the roadmap wanted.