Health checks in HLD - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a health check endpoint that returns a success status.

HLD

GET /health [1] 200 OK

Drag options to blanks, or click blank then click option'

Aresponds_with

Breturns

Csends

Doutputs

Attempts:

3 left

💡 Hint

Common Mistakes

Using verbs like 'responds_with' or 'sends' which are not standard in endpoint definitions.

The health check endpoint should return a 200 OK status to indicate the service is healthy.

2fill in blank

medium

Complete the code to specify the type of health check that verifies database connectivity.

HLD

HealthCheck: type = [1]

Drag options to blanks, or click blank then click option'

Adatabase

Bdisk

Cmemory

Dcpu

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing database check with disk or memory checks.

The health check type for verifying database connectivity is database.

3fill in blank

hard

Fix the error in the health check configuration to correctly set the check interval.

HLD

check_interval = [1] seconds

Drag options to blanks, or click blank then click option'

A5

Bfive_seconds

C'5'

Dfive

Attempts:

3 left

💡 Hint

Common Mistakes

Using words like 'five' or strings like '5' instead of numeric 5.

The interval should be a numeric value without quotes or words, so 5 is correct.

4fill in blank

hard

Fill both blanks to complete the health check response indicating service status and uptime.

HLD

response = {"status": "[1]", "uptime": [2]

Drag options to blanks, or click blank then click option'

Ahealthy

Bunhealthy

Cuptime_seconds

Duptime

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'unhealthy' for status when service is healthy.

Using incorrect key names for uptime.

The status should be healthy to indicate good service, and uptime is the correct key for uptime value.

5fill in blank

hard

Fill all three blanks to define a health check function that returns true if the service is healthy and false otherwise.

HLD

def is_healthy():
    if [1] == 'ok' and [2] < [3]:
        return True
    else:
        return False

Drag options to blanks, or click blank then click option'

Aservice_status

Bresponse_time

Ctimeout_threshold

Derror_count

Attempts:

3 left

💡 Hint

Common Mistakes

Using error_count instead of response_time or timeout_threshold.

The function checks if service_status is 'ok' and if response_time is less than timeout_threshold to decide health.

Practice

1. What is the main purpose of a health check in system design?

easy

A. To verify if system components are working properly

B. To increase the system's storage capacity

C. To speed up the system's processing power

D. To change the system's user interface

Solution

1. Step 1: Understand health check purpose

   Health checks are used to confirm if parts of a system are functioning correctly.

2. Step 2: Compare options with purpose

   Only To verify if system components are working properly matches this purpose; others relate to unrelated system improvements.

3. Final Answer:

   To verify if system components are working properly -> Option A

4. Quick Check:

   Health check = Verify system health [OK]

Hint: Health checks confirm system parts work, not improve features [OK]

Common Mistakes:

• Confusing health checks with performance tuning
• Thinking health checks change system features
• Assuming health checks increase capacity

2. Which of the following is a common way to implement a health check endpoint?

easy

A. A complex database query

B. A user login form

C. A file upload service

D. A simple HTTP GET request returning status

Solution

1. Step 1: Identify typical health check method

   Health checks often use simple HTTP GET requests to return system status.

2. Step 2: Eliminate unrelated options

   Database queries, login forms, and file uploads are not standard health check methods.

3. Final Answer:

   A simple HTTP GET request returning status -> Option D

4. Quick Check:

   Health check = Simple HTTP GET [OK]

Hint: Health checks usually use simple HTTP GET endpoints [OK]

Common Mistakes:

• Choosing complex operations for health checks
• Confusing health checks with user features
• Selecting unrelated services like file upload

3. Consider this pseudo-code for a health check endpoint:

function healthCheck() {
  if (database.isConnected() && cache.isAvailable()) {
    return 200;
  } else {
    return 503;
  }
}

What HTTP status code will be returned if the database is connected but the cache is down?

medium

A. 503

B. 500

C. 404

D. 200

Solution

1. Step 1: Analyze condition in code

   The code returns 200 only if both database and cache are healthy.

2. Step 2: Apply given scenario

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

3. Final Answer:

   503 -> Option A

4. Quick Check:

   Partial failure returns 503 [OK]

Hint: Both must be healthy for 200; else 503 [OK]

Common Mistakes:

• Assuming 200 if any component is healthy
• Confusing 503 with 404 or 500
• Ignoring the AND condition in code

4. A health check endpoint is returning 200 OK even when the database is down. What is the most likely cause?

medium

A. The HTTP status code 200 means failure

B. The database is actually up

C. The health check does not verify the database connection

D. The cache is down instead

Solution

1. Step 1: Understand health check logic

   If the endpoint returns 200 even when the database is down, it likely does not check the database.

2. Step 2: Evaluate other options

   Database being up contradicts the problem; 200 means success, not failure; cache status irrelevant here.

3. Final Answer:

   The health check does not verify the database connection -> Option C

4. Quick Check:

   Missing DB check causes false 200 [OK]

Hint: If failure shows 200, check what health check verifies [OK]

Common Mistakes:

• Misinterpreting HTTP 200 as failure
• Assuming database is up without proof
• Ignoring health check code logic

5. You design a health check for a distributed system with multiple services. Which approach best ensures accurate overall health status?

hard

A. Check only the main service's status

B. Aggregate health from all critical services before responding

C. Return 200 if any one service is healthy

D. Skip health checks to reduce network load

Solution

1. Step 1: Understand distributed system health

   Overall health depends on all critical services working well, not just one.

2. Step 2: Evaluate options for accuracy

   Aggregating health from all critical services gives a true picture; checking only main or any one service is incomplete; skipping checks loses visibility.

3. Final Answer:

   Aggregate health from all critical services before responding -> Option B

4. Quick Check:

   Aggregate all critical services for true health [OK]

Hint: Combine all critical services' health for accurate status [OK]

Common Mistakes:

• Checking only one service in distributed system
• Assuming any healthy service means overall health
• Skipping health checks to save resources