Sticky session and HA

It is implemented in DeterministicLoadBalancer. The implementation always select one instance. If the previous one is not awailable at the moment it choose a new one. It means that while a service is ready everything is working well till moment when the instance goes down. At this moment the service is in the Eureka registry but it is really inaccessible. In this period (from service crashing till unregistration) GW is calling only this exact instance and there is no replacement. All request goes to an error. After that is recognized there is not the expected instance and a new instance is taken (and used also for future calls).

I would say that this is not the correct behaviour. The better one would be to try expected instance (see sticky session first) and if it is not available then try any other. Basically do not filter only one instance, but provide all instance where the first one is from sticky session. There is also a question what to remember if the aimed instance is not used.

Start by locating DeterministicLoadBalancer and reading how it selects and remembers an instance while Eureka still reports an unavailable service. Reproduce the period between instance failure and unregistration, then verify that requests can use another available instance and that sticky-session behavior is defined when the preferred instance is unavailable.