The sweetest fruit salad recipe for energy saving services

Chapter 4. Health check

(This story begins in Chapter 0. Launching an energy-saving rocket to the stars)

As for any delivered service, we want to provide a simple but complete health check endpoint which will give us a summary of the status of the service itself and its collaborators (downstream services consumed).

To ensure that health check always responds immediately and it’s not impacted by the maximum connection limit defined for the consumed services (see previous Outbound pressure control chapter), we create a separate and independent web client for health check purposes. This means that two web clients need to be injected in the (consumed service) repository, like in this example:

open class DatasourcesAPIRepository(private val webClient: WebClient, highPriorityWebClient: WebClient, private val cache: Cache<String, SimpleDataSource>, …): DatasourcesRepository, HttpAPIRepository(highPriorityWebClient, …) {
...
}

In our case, all the consumed services extend HttpAPIRepository which provides a default health check endpoint, therefore the highPriorityWebClient is just passed to it.

Below you can see an example of the health check response, where we can easily see the overall status of the service and the status of the 2 consumed services’ connections, including the client statistics. This client-side cache will be detailed in chapter 6, coming soon):

Notice that we will take advantage of this endpoint for Kubernetes health checks.

The trip continues in Chapter 5. Profilling