Back to daily archive
Architecture/

Governance without gridlock: Idempotent integrations

JSBC Labs retrospective note4 min read

Why this deserves attention

A request may be delivered more than once; a dependable receiver must make repetition safe. Clarity here reduces both delivery risk and the long-term cost of ownership.

Retries can create duplicate orders, payments, cases or downstream actions when message identity is ignored. On 16 February 2025, this archive entry records the principle as a practical design concern rather than a product announcement.

Use proportionate control

Look at idempotent integrations through how to create control without slowing every useful change. The objective is not to introduce more process; it is to expose the few decisions that determine reliability, ownership and future change.

Carry a unique operation key, store processing state and return the prior outcome when the same request is received again. Record the decision close to the solution so that delivery, support and future architecture reviews work from the same intent.

What good looks like

Automatic retries improve resilience instead of creating a new data-quality incident. The team can describe the expected behaviour, the owner, the evidence of success and the response when reality differs from the design.

A useful next step is to review one live implementation against this principle, identify the largest unowned assumption and turn it into a bounded improvement with a measurable outcome.