# Send identical commands at exactly the same time

Sequential retries can pass while concurrent requests still duplicate an effect. Use a barrier to make two callers compete for the same operation identity.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Prepare a shared intention

Create one synthetic command, account and idempotency key. Arrange for two test clients to submit the same normalised payload concurrently.

Use a barrier or controlled server hook so both requests reach the claim boundary together. Simply starting two requests in a loop may run them far enough apart that the second sees a completed result and misses the race.

Record the target state before the test and the expected single effect. Keep external actions isolated through a test service if the command normally sends or changes something outside the database.

## Observe the claim result

The storage uniqueness or conditional-write rule should allow one request to own execution. The other should follow the documented pending or result-reuse path.

Inspect database records and downstream attempts. A successful HTTP response from both callers can be correct if both receive the same result. It is incorrect if each response describes a separately created business record.

If one caller receives a retryable pending response, retry it with the same key. Verify it eventually obtains the recorded outcome without creating a new intention.

## Change the payload under the same key

Repeat the race with one material field changed, such as the booking target or quantity. The service should preserve the first accepted binding and reject conflicting reuse according to its contract.

Use values that remain individually valid. This ensures the conflict is caught by idempotency semantics rather than ordinary input validation.

Also test a different account using the same key. The expected behaviour should follow the namespace rule without revealing another account's result.

## Interrupt the winner after its effect

Allow the winning request to commit the business change, then lose its response or stop before recording a remote result. Retry through the normal recovery path.

For a local atomic transaction, inspect that effect and result state agree. For an external operation, verify the downstream key or reconciliation prevents duplication.

Finally, count business effects and compare returned identifiers. Keep the concurrent, conflicting and uncertain-result cases separate in the report. Together they establish much more than a demonstration that clicking the same button twice usually works.

## Sources

- [PostgreSQL: INSERT and conflict handling](https://www.postgresql.org/docs/17/sql-insert.html)
- [AWS Builders' Library: idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)