Netflix Zuul and Hystrix, where to situate hystrix

[Alastair Sumpter]

I'm doing some research into creating a microservice architecture using a lot of the netflix technology. I have a zuul gateway routing to multiple microservices. A thymeleaf UI server is responsible for handling user requests and forwarding on to the gateway if needed. 

I've started looking at incorporating hystrix, I have played around with having hystrix on both the gateway and the UI server. Ideally i'd have some sort of fallback mechanism on the gateway so that if theres a microservice down the gateway can fail gracefully. I have this set up and working fine, my only problem is that because the gateway has no contextual knowledge about what the user is requiring from the microservices, the fallback has to be very generic. My other option would be to add hystrix fallbacks to the UI server, but I would like to expose the gateway as some sort of API in the future too.

Is there any options for me to provide more specific fallbacks on the gateway? Or should i move hystrix to the UI server? Or is it worth having it on both the gateway and the UI? (I'm not sure if that is overkill?)

Thanks

[Matt Jacobs]

Alastair - 

This is a great question.  We face a very similar problem in our setup.  We use Hystrix in both the Gateway (Zuul), and the layer underneath (which routes to multiple business-logic microservices).  Hystrix essentially plays 2 different roles in the 2 systems.

In Zuul, it's very hard to produce a reasonable fallback, so it's utility is limited to metrics, timeouts, and some fairly loose resource-bounding via semaphores.

In the layer underneath (the API server), there are many calls for specific pieces of functionality.  In these cases, it is possible to have good fallbacks.  As a result, we have much stricter resource bounds (either via threadpool or semaphore), and regularly induce failures in order to test that fallbacks work as expected.