Should Health Checks call other App Health Checks
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Introduction
Health checks are critical components in modern applications, ensuring systems are running smoothly and efficiently. These checks are automated processes that determine the operational status of application components. A question often arises in system design: should a health check of one application invoke health checks of other dependent applications? This article delves into the technical implications, benefits, and potential pitfalls of this approach.
Understanding Health Checks
What are Health Checks?
Health checks are procedures that determine the operational status and performance of a system. They typically:
- Check the system's availability.
- Validate response times.
- Identify system errors or failures.
- Ensure key dependencies are operational.
Types of Health Checks
- Local Health Checks - Target the application's internal components, such as memory usage, disk space, and service availability.
- Remote Health Checks - Target external dependencies, such as database connectivity, API responses, and network availability.
The Debate: Calling Other App Health Checks
Benefits
- Holistic System Awareness: Invoking health checks on dependent applications provides a more comprehensive understanding of the overall system health.
- Proactive Failure Detection: Early detection of downstream failures can prevent cascading failures and help in quicker resolution.
- Simplified Monitoring: Centralizing health checks can simplify the monitoring architecture, potentially reducing redundancies in systems.
Drawbacks
- Increased Latency: Calling other application health checks can increase response times and negatively impact system performance.
- Complex Dependencies: Creating a tightly coupled system where applications are interdependent can lead to difficult-to-troubleshoot failures.
- Potential for Downtime: If a dependent application is down, it could falsely mark the upstream application as unhealthy, leading to unnecessary mitigation steps.
Technical Considerations
Network Overhead
Performing remote health checks requires network communication, which can introduce latency and additional points of failure. It is critical to ensure that these checks are lightweight and non-intrusive.
Coupling and Dependency Management
Tightly coupling application health checks can complicate the architecture. It is essential to meticulously document dependencies and communication protocols to minimize chaos in failure scenarios.
Example Scenario
Consider a microservices architecture with Service A depending on Service B and C. If Service A includes health check calls to B and C:
Related reading
- Should I have a separate assembly for interfaces?
- Should I use AWS Elastic Beanstalk or the Amazon EC2 Container Service ECS to scale Docker containers?
- Should I use Singular or Plural name convention for REST resources?
- Should microservice know and imlement logic for specific needs of frontend?
- Should I have separate containers for Flask, uWSGI, and nginx?
- Should I take ILogger, ILoggerT, ILoggerFactory or ILoggerProvider for a library?
- should mongodb nodes in replicaset need to be time synchronized?
- Should one interface inherit another interface

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.