PROJECT / SAMPLE
Three APIs. None agreed on reality.
A small integration layer reconciled incompatible models, incomplete APIs, and side effects that could not safely happen twice.
- Date
- 2026-07
- Type
- integration / software / automation
- Status
- fictional fixture
- Published
- prototype only
Problem
An operations team reconciled three SaaS systems by hand because each exposed a partial, conflicting version of the same business event. Failures were silent until a customer noticed.
Constraints
- None of the upstream systems could be replaced.
- Several operations were non-idempotent.
- Historical records had to remain auditable.
Observed
- The same identifier meant different things in each system.
- Retries could create duplicate downstream actions.
- There was no authoritative view of partially completed work.
Work
- Defined a canonical event model at the integration boundary.
- Added idempotency keys and explicit retry policies.
- Built reconciliation and dead-letter recovery paths.
- Recorded an audit log for every state transition.
- Made incomplete synchronization visible to operators.
Decisions
- Normalize once at ingress instead of translating pairwise everywhere.
- Separate delivery retries from business-operation retries.
- Prefer visible incomplete state over a false success.
Result / SAMPLE
Routine reconciliation became automatic, while unusual conflicts arrived in a short operator queue with the evidence needed to resolve them.
- 11 hr/week → <30 min manual reconciliation
- 0 silent sync failures after rollout
- 3 systems reconciled through one event model
What we did not do
We did not build a general-purpose integration platform. The durable solution was a narrow boundary around three known systems.
Technical index
REST APIs / webhooks / event normalization / audit logging