7

What could be possible alternative solution to implement Idempotency and also handle race condition.

For ex. consider a request to add a customer to System Of Record. The customer detail will have email id as key attribute. And suppose there is API to create customer.

Consider a situation, due to duplicate requests from Client, on a time T1, two requests could land on server to create customer for same email id for ex "xyz@abc.com".

Request 1,Time T1, Email ID "xyz@abc.com" Request 2,Time T1, Email ID "xyz@abc.com"

I was looking for approaches how distributed systems handle Idempotency and Race Condition on a REST API call? I understand there are different approaches like,

  • DB Constraint
  • Distributed Lock

DB Constraint on column email id, would easily solve this. Also an option of distributed lock or using no-sql approach to check email id in cache before putting record to store is a possibility.

What are other scalable approaches, considering distributed nature?

Why want to avoid constraint is, it has impact on indexing, performance and scale.

Prakhyat
  • 989
  • 8
  • 17
  • REST does not define idempotency, but HTTP does. How a server stores data in a REST architecture is more or less an implementation detail often not of much interest to clients. A server therefore could also use its local file system or its memory to store the data at all. Answers to your question therefore may depend on what storage strategy was chosen in first place. [HTTP](https://www.youtube.com/watch?v=aQVSzMV8DWc&t=191s) is just a remote document management system whose application domain is the transfer of documents and business rules triggered are just side of the document management. – Roman Vottner Jul 28 '20 at 13:01
  • @RomanVottner I am on same page with you wrt REST. I just mean, race condition or duplicate requests at same moment T1, when making REST API calls. If you see the solution or answer trying to get, is not related to storage or HTTP. The solution or answer I want to get for race conditions on API calls, and how to make sure, system handles only one and ignores other one? This issue is not only related to storage strategy. Want to check, solutions without using DB Constraint or Distributed Lock? – Prakhyat Jul 29 '20 at 06:16
  • In regards to race conditions HTTP uses conditional requests which utilizes optimistic locking (`If-Modified-Since` (or one of its variants) or `ETag` headers) to some degree. How a system processes simultaneous requests on the same resource at the same exact time is usually implementation dependent. One might defer processing of the resource till the previous request on it has finished, an other might process them in an isolated context overriding the changes done by other intermediary requests while yet others might allow dirty reads but only allow clean writes. – Roman Vottner Jul 29 '20 at 07:56
  • @RomanVottner That is an optimistic behaviour could be used with REST apis. But how about race conditions while a domain object is created.Resource or Domain object creation wont have a reference. Thats the problem I am trying to address, two requests in race to create a entry with same email id. – Prakhyat Jul 29 '20 at 08:23
  • That is not the topic of REST. Also, HTTP does not give any promises in that regards. At its heart HTTP is just a [remote file managment system and any business rules we conclude are just a side effect of the actual document management](https://www.youtube.com/watch?v=aQVSzMV8DWc&t=191s). So, in REST you merely shuffle around documents and the managment of the transmitted documents leads to certain business rules to fire. Checking whether an upload is a duplicate is already part of the business logic and as such outside of REST or HTTP's scope actually. – Roman Vottner Jul 29 '20 at 12:22
  • 1
    @RomanVottner I echo your views. My views are same, that the problem I am stating is not related to REST. What are the alternative solutions then a distributed system can take without DB constraint or distributed lock? – Prakhyat Jul 30 '20 at 04:42

0 Answers0