Health Verification Endpoints
IdBuilder service health verification endpoints
The following table shows how IdBuilder microservices behave in several scenarios of infrastructure outage. The endpoints from the table are health endpoints with the following destination:
-
Liveness endpoint: Will be polled by Kubernetes to check, if a microservice internal state is valid. If invalid, Kubernetes will restart the pod containing ID Builder service.
-
Readiness endpoint: Will be polled by Kubernetes to check, if a microservice can accept traffic. If not, traffic to microservice pod is held.
-
Health endpoint: Will be used by monitoring to determine the health state of a microservice. This endpoint will also include information about the state of the Liveness endpoint and the Readiness endpoint.
Kubernetes Probes
The following diagram shows how Kubernetes probes verify pod’s health endpoints to determine the pod state and act accordingly.
Resilience against Portal failures
Portal is not requered for IDBuilder to be healthy. It depends only on MACMA. If the portal fails, the IDBuilder-Frontend will only be unavailable. Its API's will continue to operate as normal. Portal self has the feature that updates mudule details every 12 hours. But module responsibility is to register to the Portal. IDBuilder users Foundation Components to register in Portal. That means that retries/recovery logic is enabled.