- Microservices Design Patterns Tutorial
- Microservices Design Patterns - Home
- Microservices Design Patterns - Overview
- Decomposition Design Patterns
- Decompose by Business Capability
- Decompose by Subdomain
- Decompose by Strangler
- Integration Design Patterns
- API Gateway
- Aggregator
- Proxy
- Client Side UI Composition
- Chain Of Responsibilities
- Branch
- Database Design Patterns
- Database per Service
- Shared Database per Service
- Command Query Responsibility Segregator
- Saga
- Aysynchronous Messaging
- Event Sourcing
- Observability Design Patterns
- Log Aggregation
- Performance Metrics
- Distributed Tracing
- Health Check
- Cross Cutting Concern Design Patterns
- External Configuration
- Service Discovery
- Circuit Breaker
- Blue Green Deployment
- Useful Resources
- Quick Guide
- Useful Resources
- Discussion
Microservices Design Patterns - Health Check
Problem Statement
Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment. Now in case a database is down or cannot afford more connections then a monitoring system should raise alerts. Loadbalancer/service registry/api gateway should not redirect any request to such failed service instances. So we need to detect if a running service instance is able to take request(s) or not.
Solution
We can add a health check point to each service e.g. HTTP /health which returns the status of service health. This endpoint can perform the following tasks to check a service health −
Connections Availablity − Status of database connections or connections to infrastructure services used by current service.
Host Status − Status of host like disk space, cpu usage, memory usage etc.
Application specific logic − business logic determining service availablity.
Now a monitoring service e.g. load balancer, service registry periodically invokes the health check endpoint to check the health of the service instance.
