A question that arises is what is to be done when a service is down (returns error or timeouts). Of course, the original required functionality cannot be executed. Hystrix recommends having a fallback configured for each dependency. What a fallback does, of course, varies from case to case and depends on the requirements. There are a few generic strategies, though:

• Alternate Service: If the main service endpoint is down, a backup service might be called. For example, if the Google search service is down, maybe we can call the Bing version.
• Queue: If the operation calls for the dependency to do some work, and the output of the work is not necessary for the request to be completed, then the request can be put in a durable queue for retry later. One example is sending an email for Booking. If the Email service is down, we can queue a request for the Email in something such as Kafka.
• Cache: If a response is needed from the dependent, another strategy is to cache data from previous responses. This type of caching is called defensive caching. The cache key generally includes the dependent service identifier, the API on that dependent service, and the parameters for that API. To keep the cache from exploding in terms of space requirements, strategies such as Least-Recently Used (LRU) can be employed. Here, when space budgets are breached, the least-recently-used item in the cache is reclaimed.