Tagged integration
11 pieces
- · 9 min read
Every Third-Party API Fails Differently, So Put One Adapter Between Each One and Your Product
Integrating providers inline means every provider's schema, auth, rate limits and failure modes spread through your application, and one provider's outage empties the page instead of thinning it. One adapter per provider behind a single internal shape contains the variation where it starts. On a flight-search product this took API success from 90.6 to 98.95 percent and empty results caused by provider failure from 6.8 to 0.9 percent.
- · 10 min read
Sync The Commercial Record From Day One, And Make The Sync Idempotent
When a platform transacts and a separate system holds the customer relationship, retro-fitting the sync between them costs far more than building it with the first transaction. The integration has to be idempotent from the start, because a duplicate contact or a duplicate deal is a commercial problem rather than a technical curiosity. Most of the work is deciding which system owns which fact, before any data moves.
- · 11 min read
Who Owns This Fact? Assign Ownership Per Datum Before You Integrate, Not After
When several integrated systems each hold a version of the same fact and each can write it, there is no answer to which one is right. Not a hard answer, no answer: there is no shared clock, no shared sequence, and last-write-wins gives you determinism rather than truth. Fact ownership has to be assigned per datum before integration. This covers the single-writer rule, read-only projections with provenance, what actually happens when two systems both update, and why sync is not an answer.
- · 11 min read
OpenAPI Cannot Describe Your Events: Seven Things an Event Contract Must State
Request-response interface description formats cannot express an event-driven contract. There is no caller, there is no meaningful response, delivery is at-least-once, and ordering is not guaranteed. Teams document their events in a request-response format anyway, and the resulting document omits exactly the properties that cause incidents. Here are the seven things an event contract has to state, and how a unique index becomes the place the contract is actually enforced.
- · 8 min read
The Fan-Out Budget: Expand, Filter With Something Cheap, Spend the Paid Call Last
When one user request has to become many calls to a paid provider, cost and latency scale with the number of candidates rather than with the number of requests. The fix is an ordering: generate candidates from something you own, filter them against something cheap, and spend the expensive call only on survivors. The budget then holds per request instead of per candidate.
- · 7 min read
Four Mechanisms, Four Numbers: Why One Reliability Metric Hides the Work
An integration layer that improved API success, end-to-end failure, duplicate results and empty responses did so through four separate mechanisms. Reported as one number, you cannot tell which part earned its keep, you cannot tell when one regresses, and you cannot defend the architecture. Measure each mechanism on its own, and the gap between two of the numbers becomes the most informative thing in the report.
- · 7 min read
You Cannot Deduplicate Before You Normalise: Identity Is a Decision, Not a Property
Two records from different sources cannot be compared until they share a shape, so deduplication is downstream of normalisation whether or not anyone planned it that way. The harder half is that identity then has to be defined deliberately: nothing in the data says which fields make two records the same thing, and that choice decides both your duplicate rate and your merge errors.
- · 8 min read
At Least Once With No Replay
Inbound webhooks from major messaging and social platforms retry over an extended window and typically offer no way to request message history afterwards. That pairing produces duplicates on one side and unrecoverable gaps on the other. Deduplicating on a stable identifier and recording every receipt has to be built on day one, because an outage longer than the retry window is a permanent data loss.
- · 7 min read
Prove You Can Get the Data Before You Build the Thing That Needs It
For products whose value is access to someone else's data, the risk that ends the project is not the engineering. It is whether you can obtain the data at all, on terms that permit your use case, at a price the product can carry. That question is answerable in days for a few hundred pounds, and it is routinely answered last, after the architecture has been built on an assumption.
- · 7 min read
The Seam Is Nobody's Job: Why Failures Live Between Systems That Each Work Correctly
Three systems, each owned, each correct by its own contract, each reporting success. The failure lives in the relationship between two of them, and relationships are not assigned to anyone. That is why these defects survive code review, pass every component test, and are found by a customer rather than by a team.
- · 9 min read
One Owner, No Seams
When firmware, gateway, cloud and dashboard are split across contractors, the failures land in the seams between them, where each side can demonstrate that its own part works. A single owner across the stack removes the seam rather than managing it. This covers when one owner is genuinely better, when it is not, and what to require contractually if the split is unavoidable.