Idempotency and locking to prevent duplicate orders and payments
Prevent network retries, repeated clicks, or race conditions from creating duplicate orders or payments.
Last updated: 2026-09-18 · Owner: Flexora engineering team
Alternatives considered
- Discarded
- Process every retry as a new request and rely only on the UI flow.
- Chosen
- Record idempotency and apply a distributed locking mechanism to order creation and payment recording.
Decision made
Apply persisted idempotency and a distributed locking mechanism to order creation and payment recording.
Rationale
The combination protects against retries and fixes race conditions documented in concurrent payment operations.
Frequently asked questions
- What did Pyae decide about "idempotency and locking to prevent duplicate orders and payments"?
- Apply persisted idempotency and a distributed locking mechanism to order creation and payment recording.
- How does Pyae prevent duplicate orders from a double click or network retry?
- By applying persisted idempotency to order creation and payment recording, combined with a distributed locking mechanism. If the same order request gets retried, it won't create a second record.
- What's an idempotency key, and how does it apply to orders and payments?
- It's a unique identifier attached to a request so that if the request repeats, the system recognizes it's already been processed and skips duplicating it. Pyae persists this key on both order creation and payment recording.
- Is idempotency alone enough to prevent race conditions?
- Not always. Idempotency protects against retries of the same request, but race conditions between distinct, concurrent requests need a locking mechanism on top of that. Pyae combines both for orders and payments.
This kind of decision applies to your project too
If your operation needs custom software with technical decisions that are documented and built to last, we can help you define them.