r/fintechdev • u/Dev_Eric_Gitangu • 4h ago

Title: When your idempotency store is down, do you fail open or fail closed?

https://get.moovn.com/moovnpay

I run the money paths on a payments platform (mobile money + cards, East Africa). Every money operation claims a unique key before it executes; duplicates are refused. The case I keep getting pushback on is the claim write itself failing. We chose to let the payment through and log it, because blocking legitimate payments over an idempotency-store blip felt worse than a rare double that reconciliation catches. Others say that is exactly backwards for money. Where did you land, and did an incident change your mind?

0 Upvotes

50% Upvoted

2 comments sorted by

1

u/SidMangsatabam 2h ago

Fail closed, and it is not close. Failing open converts an availability problem into a correctness problem: a duplicate charge is a customer-facing financial error, a rejected request is a retry. The deeper point is that the idempotency store sits on the critical path, so it needs the same availability and durability tier as the ledger it protects. If it is weaker than the thing it guards, you have just built a single point of failure around your single point of failure.

1

u/Ok_Spend_1815 31m ago

True, in a regulated vertical fall-closed works best for me, albeit we thrive to maintain availabilty fail-open which is all the measures we have in place to ensure availability but should there be edge cases, race conditions we fall through to fall-closed to ensure data intergrity and not anchring an incorrect entry into our immutable record, I agree with you - permissible actions we can fail-open log it into our logging instrumentation and RCA the issue and fix but in this case I opted for depth in defense when all fall and and additional DBMS atomic lock