AI Engineer Portal

Your personal operating system for career transition.

Private mode

Exercise

Implement graceful degradation with multi-level fallback tiers

Implement Graceful Degradation with Fallback Tiers

When the primary LLM provider goes down, the options are: fail hard, use cached responses, try a backup model, or return a template. A degradation chain tries each tier in sequence.

What to build

DegradationChain(primary_fn, fallback_fn, cache_fn, template_fn):

Each fn is async (query: str) -> str | None. None signals unavailability.
async respond(query) -> DegradationResult — tries tiers in order, returns first non-None result
If all return None, use a hardcoded unavailable message

DegradationResult: content, tier: DegradationTier, degraded: bool, tiers_attempted: int DegradationTier enum: PRIMARY, FALLBACK_MODEL, CACHED, TEMPLATE

Constraints

Sequential (not parallel) fallback
Exceptions from a tier are caught and treated as unavailability

Api Async / hard / Step 18 of 23

Practice stage

Async and provider control

Hint

Make waiting behavior explicit. Timeouts, retries, and concurrency limits matter more than squeezing everything into one helper.

Next drill

Build a persistent semantic cache

Success criteria

- Uses async boundaries coherently
- Makes timeout and retry decisions legible
- Would be maintainable under provider instability

Review checklist

- 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.