Connecting to Accounting, CRM and Everything Else
Last updated:
Never call external systems in a request
An external call during a web request makes the request as slow as the other system and as reliable as it is. Both are outside your control.
Queue it. The user gets an immediate response, the call is retried automatically, and a provider outage becomes a delay rather than a failure.
The four requirements
- Idempotency — derive a reference from your record so a retry cannot duplicate
- Retries with backoff for transient failures
- A durable queue, so nothing is lost during an outage
- Reconciliation — a daily comparison of sent against arrived
Record the integration state
- Which records have been sent, and when
- The external system's identifier for each
- What failed and why
- What is queued and how long it has waited
- Enough to answer “where is this?” in seconds
Map the data explicitly
| Decision | Why |
|---|---|
| Which system owns each field | Prevents overwriting |
| How values map between them | Terminology differs |
| What happens on conflict | It will happen |
| What is not synchronised | Clarity |
| How the mapping is versioned | It will change |
The mapping is business work rather than technical work, and it is where the time goes on most integration projects.
Reconcile daily and alert on nothing
A daily comparison catches silent divergence the same day. And an alert when nothing has been sent catches the integration that stopped entirely.
That second alert is the one that prevents a broken integration running unnoticed for a month.
Frequently asked questions
What if the other system has no API?
How do we handle their rate limits?
What about their outages?
How much does an integration cost?
Data retyped between your system and another?
Tell us which systems and what moves between them. We will scope a proper connection.
Related services
What we build for problems like this one