Cohesive Systems logoCOHESIVE SYSTEMS

Search Cohesive Systems

Ready

Search Cohesive Systems

Find product pages, building blocks, technical articles, and graph definitions.

Idempotency

Idempotency is the property that repeated handling of the same semantic input does not produce duplicate domain effects.

Idempotency is required when delivery, retry, replay, or recovery can cause the same input to be observed more than once.

Idempotency may be based on:

  • Command ids.
  • Event ids.
  • Expected versions.
  • Entity versions.
  • Deduplication records.
  • Natural business keys.
  • Receiver-side effect tracking.
  • Transactional inbox records.

In the model, duplicate input may produce an applied no-change or prior-result outcome for the target entity: the observer saw and interpreted the input, but no new domain transition effect was committed. The typed outcome is not an event.

Idempotency is scoped to a semantic input and an effect boundary. An HTTP retry, broker redelivery, workflow replay, and outbox republication may each need a different idempotency key or deduplication record.

Relation to Fixed Points

Fix a semantic input ii, and let HiH_i describe how handling that input transforms the relevant domain-effect state. Operational idempotency requires repeated handling to be equivalent to handling the input once:

Hi(Hi(s))Hi(s)H_i(H_i(s)) \sim H_i(s)

If s=Hi(s)s' = H_i(s), then Hi(s)sH_i(s') \sim s'. The result is therefore a fixed point of the handling transformation up to the equivalence declared at the effect boundary; it is a literal fixed point when \sim is equality.

This does not require every part of operational state to stop changing. A duplicate attempt may add a log entry, metric, trace, or audit observation while leaving the relevant domain effects unchanged. Idempotency is the scoped property of the handling transformation; the fixed point is its invariant result under that scope.

Enterprise Integration Patterns calls the consumer-side application of this discipline an Idempotent Receiver. The pattern is one realization of scoped semantic idempotency; it does not make an arbitrary external effect idempotent merely by deduplicating message delivery.

Formal relations

  • qualifies: Effect Models — States when repeated handling of one semantic input preserves the same logical consequences at the declared effect boundary.

External References

Related concepts: enterprise integration patterns, fixed points, equivalence vs equality, retry, delivery semantics, acknowledgments, commit boundaries, effects, command, transition, version, recovery, transactional inbox, outbox.