Health check endpoints in HLD - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a health check endpoint in a system?

A health check endpoint is a special URL or API in a system that reports if the system or service is working properly. It helps monitor system health by returning status like 'healthy' or 'unhealthy'.

intermediate

Why are health check endpoints important in distributed systems?

They help detect failures early, enable automatic recovery or load balancing, and improve system reliability by providing real-time status to monitoring tools.

beginner

Name two common types of health checks used in endpoints.

1. Liveness check: verifies if the service is running and not stuck.
2. Readiness check: verifies if the service is ready to handle requests.

intermediate

What should a health check endpoint avoid doing to keep the system efficient?

It should avoid heavy computations, long database queries, or complex logic. It should respond quickly with simple checks to prevent adding load or delays.

advanced

How can health check endpoints help with auto-scaling in cloud environments?

Auto-scaling systems use health check results to decide when to add or remove instances. If many instances report unhealthy, new ones can be started to maintain performance.

What does a readiness health check indicate?

A If the service is ready to accept traffic

B If the network is slow

C If the database is down

D If the service is running and not stuck

Readiness checks confirm if the service is ready to handle requests, unlike liveness checks which verify if the service is running.

Which of the following is NOT a good practice for health check endpoints?

A Perform heavy database queries

B Respond quickly with simple status

C Return HTTP 200 when healthy

D Separate liveness and readiness checks

Health checks should avoid heavy operations to keep the system responsive and avoid extra load.

What HTTP status code usually indicates a healthy service in a health check endpoint?

A 404

B 500

C 200

D 302

HTTP 200 means OK, indicating the service is healthy.

How do health check endpoints assist load balancers?

A By encrypting traffic

B By providing service health status to route traffic

C By storing user sessions

D By caching static files

Load balancers use health check results to send traffic only to healthy instances.

Which type of health check would detect if a service is stuck in an infinite loop?

A Security check

B Readiness check

C Performance check

D Liveness check

Liveness checks detect if the service is alive and not stuck or crashed.

Explain the difference between liveness and readiness health check endpoints and why both are useful.

Think about service running status versus ability to serve requests.

Describe best practices for designing efficient health check endpoints in a scalable system.

Focus on performance and clarity of health status.

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