Skip to content

Strategy & Systems Design

Integration architecture: decide who owns each record, then connect

When a customer's phone number lives in three systems and anyone can edit it in any of them, the systems will disagree, and no amount of syncing fixes that. Decide first which system owns each kind of record. Then every sync has a direction, every conflict has a rule, and every failure has somewhere to go.
Talk through your connectionsSee what's decided ↓
office appaccountingtexting servicepayment providercustomer contactownscopycopyappointmentownscopyjob and photosownsinvoiceownscopypaymentcopycopyownsthe booksownsupdatedretry in 1 minupdatedJ.H. changes their phone number in the customer accountSomeone edits J.H.'s address directly in accountingAccounting doesn't own it: the edit goes to the office lead, who decides which is right

Decided for every connection

Six answers per connection, written down before any of them is built.

  1. 01

    Who owns the record

    The only system that may change it

    Every other system holds a copy and takes updates from the owner.

  2. 02

    Which way it flows

    From the owner, outwards

    A copy never writes back over the owner. An edit made in a copy is sent to a person.

  3. 03

    What starts it

    A change, or a schedule

    Sent the moment something changes where the other system can take it; on a schedule where it can't.

  4. 04

    How it signs in

    Its own key, only the access it needs

    Each connection has its own credentials, so one can be replaced without touching the rest.

  5. 05

    What happens when the other side is down

    Retried, safely

    Waiting longer each time, and never creating the same record twice.

  6. 06

    Where failures go

    To the person who can fix them

    A rejected invoice goes to finance with the reason; a bad phone number goes to the office.

The sync rules, written down

One line per kind of record. This is what the connections are built from.
Customer contactaccounting and the texting service, when it changesretried; after an hour, shown to the office
Appointmentthe texting service, when it's booked or movedretried; a reminder that can't go is shown to the office
Invoiceaccounting, once it's approved (straight away under $2,500)rejections go to finance with the reason, not retried
Paymentthe office app and accounting, when the payment provider reports itrecorded once, even if it's reported twice
The booksnowhere: they stay in accountingnothing to sync

Three failures, planned for

Each one has a different answer, decided before it happens.

J.H.'s new phone number → texting service

  1. Sent

    texting service unavailable

    failed

  2. Wait 1 minute

    done

  3. Sent again

    updated

    done

The office app never waited, and the next reminder used the new number.

What it's drawn from, and what gets built from it

Drawn from

Current-state map
what holds what today
Solution architecture
the parts
Each system's limits
what it can send and take
Integration architecture
owners, flows, sync and conflict rules

Built as

API integrations
each connection
Data synchronization
copies kept in step
Monitoring
failures reach a person

Worth doing when your systems disagree

Good fit

  • Your tools disagree about the same customer or job.
  • You're adding a system and need to know what it will own.
  • Sync failures are found by customers, or at month-end.

Not the right fit

  • Two tools, one direction, one kind of record. Just build the connection.
  • Everything already lives in one system.

Where this capability is used

Next to integration architecture

Questions about integration architecture

What does “source of truth” mean?

The one system allowed to change a kind of record. Every other system holds a copy and takes updates from it.

What if two systems both need to edit a record?

We pick one owner and route edits through it, or split the record so each system owns its part, like the office app owning the invoice and accounting owning the books.

Do we need an integration platform?

Not always. A few direct connections can be fine. A hub earns its place when there are many systems and you want one place to see every sync.

What about a system with no way to connect to it?

Scheduled exports and imports, under the same ownership rules. It's slower, so the design says how out of date each copy is allowed to be.