Health check endpoints in HLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Purpose of Health Check Endpoints

What is the primary purpose of a health check endpoint in a distributed system?

A To provide detailed logs of system errors to developers

B To manage database schema migrations automatically

C To allow external systems to verify if a service is running and responsive

D To store user authentication tokens securely

💡 Hint

Think about what external systems need to know to decide if a service is healthy.

Health check endpoints are designed to let other systems or load balancers know if a service is alive and responsive, so they can route traffic accordingly.

❓ Architecture

intermediate

Designing a Health Check Endpoint

Which design best describes a simple health check endpoint that returns HTTP 200 OK only if the service and its database are reachable?

A Endpoint checks service status and database connectivity, returns HTTP 200 OK if both are healthy, else HTTP 503

B Endpoint returns HTTP 200 OK without checking any dependencies

C Endpoint returns HTTP 500 Internal Server Error if the service is healthy

D Endpoint only checks database connectivity and ignores service status

💡 Hint

Consider what components must be healthy for the service to be considered healthy.

A robust health check endpoint verifies both the service itself and critical dependencies like the database. It returns HTTP 200 OK only if all checks pass, otherwise HTTP 503 to indicate unavailability.

❓ scaling

advanced

Scaling Health Check Endpoints in Microservices

In a microservices architecture with hundreds of services, what is the best approach to efficiently perform health checks without overwhelming the system?

A Each service only checks its own health and ignores dependencies

B Each service performs health checks on all other services synchronously on every request

C Disable health checks to reduce network traffic

D Use a centralized health aggregator that periodically polls each service's health endpoint asynchronously and caches results

💡 Hint

Think about reducing load and avoiding synchronous calls across many services.

A centralized health aggregator asynchronously polls each service's health endpoint and caches the results. This reduces network load and avoids cascading delays or failures.

❓ tradeoff

advanced

Tradeoffs in Health Check Endpoint Complexity

What is a key tradeoff when designing a health check endpoint that performs deep checks (e.g., database, cache, external APIs) versus a simple ping check?

A Deep checks increase response time and risk false negatives, while simple checks may miss critical failures

B Simple checks provide detailed error logs, deep checks do not

C Deep checks always improve performance, simple checks cause system crashes

D Deep checks reduce network traffic, simple checks increase it

💡 Hint

Consider the balance between thoroughness and speed.

Deep health checks provide more accurate status but can slow down responses and cause false alarms if dependencies are slow. Simple checks are fast but might miss issues.

❓ estimation

expert

Estimating Load on Health Check Endpoints

A service has 100 instances behind a load balancer. The load balancer performs health checks every 10 seconds. Each health check request consumes 5ms CPU time on the instance. Estimate the total CPU time spent per second on health checks across all instances.

A 5 ms per second

B 50 ms per second

C 500 ms per second

D 1000 ms per second

💡 Hint

Calculate how many health checks happen per second and multiply by CPU time per check.

Each instance receives 1 health check every 10 seconds, so 0.1 checks per second per instance. For 100 instances, total checks per second = 100 * 0.1 = 10. Each check uses 5ms CPU, so total CPU time = 10 * 5ms = 50ms per second.

Practice

1. What is the primary purpose of a health check endpoint in a system?

easy

A. To verify if the service is alive and functioning

B. To store user data securely

C. To handle user authentication

D. To serve static website content

Solution

1. Step 1: Understand the role of health check endpoints

   Health check endpoints are designed to tell if a service is alive and working properly.

2. Step 2: Identify the correct purpose among options

   Only To verify if the service is alive and functioning describes checking the service's health, while others describe unrelated functions.

3. Final Answer:

   To verify if the service is alive and functioning -> Option A

4. Quick Check:

   Health check = Verify service alive [OK]

Hint: Health checks confirm service status, not data or auth [OK]

Common Mistakes:

• Confusing health check with authentication
• Thinking health check stores data
• Assuming health check serves website content

2. Which URL path is commonly used for a readiness health check endpoint?

easy

A. /ready

B. /health

C. /status

D. /check

Solution

1. Step 1: Recall standard health check paths

   Readiness endpoints typically use the path /ready to indicate if the service is ready to accept traffic.

2. Step 2: Match the correct path

   Among the options, only /ready is the standard path for readiness checks.

3. Final Answer:

   /ready -> Option A

4. Quick Check:

   Readiness path = /ready [OK]

Hint: Readiness = /ready, Liveness = /health [OK]

Common Mistakes:

• Using /health for readiness instead of liveness
• Confusing /status or /check as standard paths
• Mixing readiness and liveness endpoints

3. Consider this pseudocode for a health check endpoint:

if database.isConnected() and cache.isAvailable():
    return 200
else:
    return 503

What HTTP status code will the endpoint return if the database is connected but the cache is down?

medium

A. 200

B. 503

C. 404

D. 500

Solution

1. Step 1: Analyze the condition logic

   The endpoint returns 200 only if both database.isConnected() and cache.isAvailable() are true.

2. Step 2: Evaluate the given scenario

   Database is connected (true), cache is down (false), so condition fails and returns 503.

3. Final Answer:

   503 -> Option B

4. Quick Check:

   Both must be true for 200; else 503 [OK]

Hint: Both services must be healthy for 200 OK [OK]

Common Mistakes:

• Assuming 200 if only one service is healthy
• Confusing 503 with 404 or 500
• Ignoring the AND condition in the code

4. A health check endpoint code snippet:

def health_check():
    if db.connected() or cache.available():
        return 200
    else:
        return 503

What is the main problem with this health check logic?

medium

A. It does not check any services

B. It returns 503 when both services are healthy

C. It returns 200 even if only one service is healthy

D. It uses incorrect HTTP status codes

Solution

1. Step 1: Understand the logical operator used

   The code uses OR, so it returns 200 if either db.connected() or cache.available() is true.

2. Step 2: Identify the issue with health check accuracy

   This means it reports healthy even if one service is down, which can mislead monitoring systems.

3. Final Answer:

   It returns 200 even if only one service is healthy -> Option C

4. Quick Check:

   OR allows partial health, which is incorrect [OK]

Hint: Use AND to ensure all services are healthy [OK]

Common Mistakes:

• Using OR instead of AND in health checks
• Ignoring partial failures in health status
• Misinterpreting HTTP status codes

5. You design a system with a /health endpoint for liveness and a /ready endpoint for readiness. Which of the following best describes when the /ready endpoint should return HTTP 503?

hard

A. When the service is completely down and unreachable

B. When the service is alive and ready to accept traffic

C. When the service is overloaded but still responding

D. When the service is alive but not ready to accept traffic due to missing dependencies

Solution

1. Step 1: Understand readiness vs liveness

   Liveness (/health) checks if service is alive; readiness (/ready) checks if it can handle requests safely.

2. Step 2: Identify readiness failure condition

   Readiness returns 503 if dependencies (like database) are missing, so service should not receive traffic yet.

3. Final Answer:

   When the service is alive but not ready to accept traffic due to missing dependencies -> Option D

4. Quick Check:

   Readiness 503 = alive but not ready [OK]

Hint: Ready means all dependencies OK; else 503 [OK]

Common Mistakes:

• Confusing liveness failure with readiness failure
• Returning 503 when service is fully down (should be liveness)
• Assuming overload means readiness failure