AI Engineer Portal
Your personal operating system for career transition.
Exercise
Build a health check endpoint for an LLM service
Build a Health Check Endpoint for an LLM Service
A production LLM service needs two health endpoints with different semantics. A naive /ping -> 200 is useless — it does not tell you whether the model is loaded, whether the provider API is reachable, or whether the service can handle a request.
What to build
Implement a HealthChecker class and two endpoint functions:
-
HealthChecker:mark_fatal(reason: str)— marks the service unrecoverable (liveness will fail)set_model_loaded(loaded: bool)set_provider_healthy(healthy: bool)set_cache_healthy(healthy: bool)— non-critical
-
liveness_check(checker) -> tuple[dict, int]:({"status": "ok"}, 200)unless fatal;({"status": "fatal", "reason": "..."}, 503)if fatal
-
readiness_check(checker) -> tuple[dict, int]:- HTTP 503 if model not loaded OR provider unhealthy
- HTTP 200, degraded=True if only cache is unhealthy
- HTTP 200, degraded=False if all pass
Why this matters
In Kubernetes, liveness failure triggers a container restart; readiness failure only removes the pod from rotation. LLM services loading models at startup need generous startup probes — conflating liveness and readiness causes unnecessary restart loops.
Api Async / medium / Step 14 of 23
Async and provider control
Make waiting behavior explicit. Timeouts, retries, and concurrency limits matter more than squeezing everything into one helper.
- - Uses async boundaries coherently
- - Makes timeout and retry decisions legible
- - Would be maintainable under provider instability
- - Is timeout behavior explicit?
- - Is retryable failure separate from terminal failure?
- - Would logs reveal what actually timed out?
Practice
Generate a variation
Generate a new exercise variation to deepen understanding or practice a related concept.
Attempt history
Recent submissions
Before you submit, decide what a strong answer should make obvious to the reviewer.
No attempts yet.