how do i make a payment-style post endpoint safe to retry?
ahh classic two things to check. Also validate that a reused key comes with the same request body. If a client accidentally reuses a key for a different order, you should return an error rather than silently replaying teh old response. Store a hash of teh request payload with the key and compare. good luck man!
its a public api so i cant really force them to change how they send requests, but i'm hoping to implement an idempotency-key header. i want the clients to generate a unique uuid and send that with their order request so my backend can track it. i dont want to have to manually check every single request body cuz that would be a nightmare lol!!
honestly, if u dont want to manually hash every body, u gotta be careful. just checking the header isnt enough cuz a malicious client could send the same uuid with different item amounts or addresses... thats how u end up with successful duplicates that look different.
in a setup like mine, i'd just store the idempotency key in a fast cache like redis with a TTL. when the request hits, check if the key eixsts. if it does, just return teh cached response. if it doesnt, process the order and save teh result. it keeps the db clean and stops the double-processing before it even hits your order logic. also, make sure your DB transaction wraps the 'check key' and 'create order' steps sooo u dont get race conditions if two identical requests hit at the exact same millisecond. 🙄
Related topics
- Preflight Request Failing For A JSON POST From My Frontend
- our four-person team wants protobufs everywhere. should i push back?
- is it nginx or the spring boot app? a 502 mystery with one clue
- monday 8am and the ruby job runner is dying with signal 11
- INTERNAL APIS: BORING REST VS SHINY GRPC. CONVINCE ME EITHER WAY
- IS MY VENV HAUNTED? DOTENV VANISHES THE MOMENT THE DOCKER IMAGE TAKES OVER !!
Reply to this topic
Sign in or create an account to reply.
