By the way this is the Jira ticket https://issues.apache.org/jira/browse/FINERACT-1420
El dom, 31 oct 2021 a las 21:43, VICTOR MANUEL ROMERO RODRIGUEZ (< [email protected]>) escribió: > Hello Dev Community, > > For this case that James presented a few days ago, this is the proposal. > In this way the suggested http verbs (PUT/POST/PATCH) handled by fineract > can implement the Idempotency and make Fineract a more robust platform > having a way to implement retry mechanism in the client application. > > Local testing has been passed. Although it requires a new piece for the > cache (Redis). > > This is the link in case of issues while receiving attachments > > > https://docs.google.com/presentation/d/13lw2JqE9ujHVFwmynjJcVIUA3NfcDkbs729VLgadIXE/edit?usp=sharing > > Best regards. > > Victor > > El vie, 22 oct 2021 a las 12:58, James Dailey (<[email protected]>) > escribió: > >> Devs - >> >> Through a conversation with a computer science person, I've learned that >> Fineract should have a clearly articulated approach with regard to >> idempotency. This is particularly true when thinking about how fineract >> interacts with payment systems. >> >> "When building a system to move money, it is paramount that operations >> that move money are idempotent. Failure to do this might result in >> accidentally double charging your customer, or paying a vendor multiple >> times. The risk of this happening is elevated based on the way software is >> typically built today, since developers take advantage of scalable systems >> that process multiple items in parallel. " >> ( >> https://www.moderntreasury.com/journal/why-idempotency-matters-in-payments >> ) >> >> Or this article on Stripe engineering calling for liberal use of >> Idempotency: >> >> "The easiest way to address inconsistencies in distributed state caused >> by failures is to implement server endpoints so that they’re idempotent, >> which means that they can be called any number of times while guaranteeing >> that side effects only occur once." (https://stripe.com/blog/idempotency) >> >> >> and this article in Apache Camel >> >> https://camel.apache.org/camel-kafka-connector/latest/user-guide/idempotency.html >> >> So, my understanding may be wrong and we've got this covered, or maybe we >> just consider this overkill. Perhaps there is something in the "magic" >> that's developed in the CQRS plus in-memory database queuing and our clever >> transaction state management, but... I don't know. >> >> Or perhaps we haven't really had to think about this because we haven't >> had that many large scale deployments and the scalability issues associated >> with multiple parallel calls haven't come to the fore, or haven't come back >> to the list. So, that's the intent of this email. >> >> Do we have a need now for layering on Idempotency checks? What is the >> right approach? Has anyone already implemented this, or decided not to for >> very good reasons? What would be the right approach to this? Implement >> where? Time limited to 3 hrs? Etc... >> >> So, this is a call to discuss. I'm far from an expert on this. >> >> >>
