Feb 17
Loading video player...
🧠 This is a classic retry problem and the correct solution is idempotency. - First I will introduce an Idempotency Key. The client must send a unique key with every payment request. For example a UUID generated on the client side.When the request hits the server I will first check in the database whether this idempotency key already exists. If it exists I will immediately return the stored response instead of processing the payment again. If it does not exist I will start a database transaction. Inside that transaction I will process the payment create the order and store the idempotency key along with the final response in a table. I will also put a unique constraint on the idempotency key column so even if two requests hit at the exact same time the database itself will prevent duplicate entries. Additionally I will add a unique constraint on payment_id in the orders table. This ensures that even if application logic fails the database will never allow duplicate orders for the same payment. So the full protection is Client generated idempotency key Database level unique constraint Transaction to keep operations atomic Return same response on retries This guarantees that even under network retries concurrency or mobile app resubmissions only one order will ever be created. This is the difference between writing APIs and designing production safe systems. Like Share Follow for more And save this reel for later #apis #api #backend #systemdesign #ai