[Chapter 13.2.2] Why not including RabbitMQ in the computation of the readiness state

[ongiant]

After reviewing the code in Listing 13.10, I examined the application.yml file within the Dispatcher Service. I didn't come across the management.endpoint.health.group.readiness.include property. I was under the impression that this property should be present and include rabbitmq in the computation of the readiness state. Shouldn't this be the case?

[ThomasVitale]

@ongiant that decision is up to the specific case. By default, the readiness endpoint only takes into account the capability of the Spring Boot application to process requests. Based on the specific application requirements, you might want to include additional components to the computation of the readiness endpoint. For example, Edge Service cannot really process any HTTP request if the integration with Redis doesn't work, so in the book we include "Redis" to the readiness health group. The result is that Kubernetes doesn't forward traffic to an instance of Edge Service for which the Redis integration is not working until it's up again.

In the case of Dispatcher Service, the application doesn't process HTTP requests. Since there's no traffic forwarded via Kubernetes (all requests comes from the RabbitMQ queues), we didn't include RabbitMQ in the computation of the health group because we don't need Kubernetes to do anything if some of the instances of Dispatcher Service cannot momentarily call RabbitMQ. The application will self-heal by itself once RabbitMQ become available again.

[ThomasVitale]

If you have more questions, feel free to comment on this issue or open a new one. Thank you!