Note
One writer per rail.
When two systems can write the same record and the platform gives you nothing to deduplicate on, agreement between teams is the only control you have.
Most integration advice is about getting data from one system into another. The harder problem is the opposite: making sure two systems that could both write a record agree on which one does.
The situation
A firm runs a practice management platform holding client trust balances. Two separate systems now have reason to post to it — one recording payments as they arrive from the gateway, another recording them as invoices are settled.
Both are correct. Both are useful. Together they double the trust balance.
And the platform's transaction records carry no external identifier field, so there is nothing to key on. Neither system can look at a record and tell whether it wrote it, the other system wrote it, or a human keyed it in last Tuesday.
Why the obvious fixes do not work
- Deduplicate on amount and date — this firm bills identical instalments days apart, routinely. Merging them loses real money.
- Check before writing — two processes can both check, both see nothing, and both write. A check is not a lock.
- Write a marker into a description field — workable as a backstop, and we do it, but it only detects our own writes, not the other system's.
- Reconcile nightly and fix duplicates — a trust ledger that is wrong for eighteen hours is a compliance problem, not a data-quality one.
Doubling a trust balance is not a defect you fix next sprint. It is client money, and the regulator does not grade on intent.
The rule
One writer per rail. Before either system ships, the two teams agree in writing which system owns each kind of record. Everything else reads.
In our case the line was: we write trust deposits only — no bills, no allocations, no payment links. The other system owns everything downstream of an invoice. It took ten minutes to agree and it is the reason two systems coexist on one ledger without corrupting it.
How to apply it
- List every record type in the shared system. For each one, name the single owning system. Write it down where both teams can see it.
- Where a platform offers an external-id field, use it — it turns the agreement into an enforceable constraint rather than a convention.
- Where it does not, treat the boundary as load-bearing: raise it before shipping, not after the first duplicate.
- Build the reconciliation anyway. It is how you find out the agreement was broken, and someone will break it eventually.
The broader version of this rule: for any fact in a business, exactly one system should own it and everything else should read it. Most integration pain is the cost of never having decided.
Want to know whether this applies to your firm?
Thirty minutes, an honest read on where your friction actually is, and a recommendation. If we are not the right fit, we will tell you.
Book an Operational Strategy Call