Why Idempotency Matters More Than Retries in Microservices
Why a Timeout Makes Retrying Dangerous
Retries are easy to configure in a microservice architecture. Most frameworks can repeat a failed HTTP call with a small amount of code, exponential backoff, and a maximum attempt count. The ease of implementation often leads teams to configure retries before answering the more important architectural question: is the business operation safe to execute again?
In a distributed system, a timeout is not a failure result. It is an absence of certainty.
Consider an Order Service that sends a payment instruction to a Payment Service. The Payment Service may validate the request, authorize the charge, commit the transaction, and return a successful response. If that response is delayed or lost, the Order Service records only a timeout. It cannot determine whether the payment was rejected, is still being processed, or has already completed.
Repeating the request without resolving that ambiguity can convert a temporary...
Copyright of this story solely belongs to hackernoon.com. To see the full text click HERE
