08. Write operations, idempotency and concurrency

Robust integrations are not characterized by the fact that nothing ever goes wrong. They are characterized by the fact that the same step can be safely attempted again after an error.

The interface as a product

Idempotence permanently connects an external event with exactly one X-ERP process. RowVersion or a comparable version value protects against lost updates when users and integration work in parallel.

This makes the connection robust

1. Generate a stable idempotency key for each business transaction.
2. Before POST/Retry, search for this key and save the X-ERP ID.
3. Before updating, read the current status and its version information.
4. Submit only approved changes; treat conflicts as their own queue.
5. Repeat only proven transient errors with limited exponential backoff and jitter.
6. If there are technical errors, stop them and demand correction.

Prove production readiness

• The same request can arrive multiple times, but is effective once.
• Parallel user changes are recognized, not overwritten.
• The number of retries and the total duration are limited.
• Dead letter/clarification cases have context and ownership.

Mistakes that only become expensive during operation

• Every error is answered with Retry.
• PUT sends outdated entire object and deletes new values.
• Random UUID per retry prevents finding the original operation again.

This is what you take with you

Writing becomes a controlled state machine instead of a series of hopeful HTTP calls.

Further information / source

Related topics

1. For integration specialists – connect APIs and external systems › 07. Connect receipts and warehouses in a controlled manner
2. For integration specialists – connecting APIs and external systems › 09. Error diagnosis, logging and restart
3. For integration specialists – connecting APIs and external systems › 10. Testing, acceptance and production operations

Frequently asked questions