Approach to gracefully resolve retry storms

An apparatus comprising:

• a lock module configured to, in response to receiving an incoming service request and establishing a call chain of pods of a service mesh network, set a retry locker parameter to a locked state for at least each pod in the call chain except for a last pod in the call chain, the incoming service request requiring a subsequent service request and a response from three or more pods in the call chain, the call chain comprising the three or more pods in a linear sequence, the retry locker parameter of a pod of the call chain in the locked state preventing the pod from initiating retries of a service request to a subsequent pod of the call chain;
• a single unlock module configured to, in response to determining that a status of a pod in the call chain is unavailable for responding to a service request from a previous pod in the call chain, set the retry locker parameter to an unlocked state for the previous pod, the unlocked state allowing a retry of a service request to the pod that is unavailable;
• and
• an unlock module configured to, in response to the previous pod reaching a retry limit, set the retry locker parameter to unlocked for each pod in the call chain and send a service termination message to a service requester that sent the incoming service request.

A computer program product comprising a non-transitory computer readable storage medium storing code, the code being configured to be executable by a processor to perform operations comprising:

• in response to receiving an incoming service request and establishing a call chain of pods of a service mesh network, setting a retry locker parameter to a locked state for at least each pod in the call chain except for a last pod in the call chain, the incoming service request requiring a subsequent service request and a response from three or more pods in the call chain, the call chain comprising the three or more pods in a linear sequence, the retry locker parameter of a pod of the call chain in the locked state preventing the pod from initiating retries of a service request to a subsequent pod of the call chain;
• in response to determining that a status of a pod in the call chain is unavailable for responding to a service request from a previous pod in the call chain, setting the retry locker parameter to an unlocked state for the previous pod, the unlocked state allowing a retry of a service request to the pod that is unavailable;
• and
• in response to the previous pod reaching a retry limit, setting the retry locker parameter to unlocked for each pod in the call chain and sending a service termination message to a service requester that sent the incoming service request.