Excellent article, one classic concurrency caveat though: what happens if the the same request (same X-Idempotency-Key) arrives just after the transaction is committed and the hSet call? In this case we charge the customer twice. Very small chance, but this is what we are talking here, edge cases :).
The same can happen between hGet and the processing step.
HSETNX can be used instead of hGet + hSet.
For SQL databases, a SELECT FOR UPDATE could be used as an alternative.
Greate article! Thank you
Excellent article, one classic concurrency caveat though: what happens if the the same request (same X-Idempotency-Key) arrives just after the transaction is committed and the hSet call? In this case we charge the customer twice. Very small chance, but this is what we are talking here, edge cases :).
The same can happen between hGet and the processing step.
HSETNX can be used instead of hGet + hSet.
For SQL databases, a SELECT FOR UPDATE could be used as an alternative.
Another approach is to use a Laravel Cache lock: https://laravel.com/docs/11.x/cache#atomic-locks
Nice catch! I didn't know about HSETNX, thanks for the tip