Skip to main content
ABV’s prompt management is highly available through multi-layer caching and robust infrastructure. For most applications, the default SDK caching provides sufficient resilience. However, mission-critical systems requiring absolute guarantees can implement pre-fetching or fallback prompts to eliminate any dependency on ABV’s availability.
Implementing guaranteed availability is usually unnecessary and adds complexity to your application. ABV Prompt Management is highly available due to multiple caching layers, and we closely monitor performance (status page). Consider these strategies only for mission-critical applications with zero-downtime requirements.

Understanding the Failure Scenario

Before implementing guaranteed availability, understand when and why prompt fetching can fail:
Typical request flow:
  1. Application starts, first get_prompt() call fetches from ABV API
  2. Prompt is cached locally in SDK (60-second TTL default)
  3. All subsequent get_prompt() calls return from cache (<1ms, zero network)
  4. After TTL expiry, background revalidation updates cache
  5. Cycle repeats
Network dependency: Only the first fetch and background revalidations require network access.ABV outage impact: If ABV becomes unavailable, cached prompts continue working until the cache expires. Even after expiry, stale-while-revalidate means the cached prompt is still served.Conclusion: Most applications experience zero impact from brief ABV outages due to caching.
Prompt fetching fails only when all of these conditions are true simultaneously:
  1. No cached prompt: Fresh application startup, or fetching a prompt name for the first time
  2. Network request to ABV fails: After retries (typically 3 attempts)
  3. No fallback configured: Application didn’t provide a fallback prompt
When this occurs:
  • Application deployment to new instances during ABV outage
  • Kubernetes pod restart during ABV outage
  • First use of a new prompt name when ABV is unreachable
Frequency: Extremely rare. Requires both ABV unavailability and cold start timing.Without guaranteed availability: get_prompt() raises an exception, application must handle error.
ABV’s high availability:
  • Multi-region deployment with automatic failover
  • 99.9% uptime SLA
  • Public status page with real-time monitoring
  • Multiple caching layers (SDK cache, API Redis cache, database fallback)
SDK resilience:
  • Caching eliminates network dependency for most requests
  • Stale-while-revalidate ensures zero downtime during cache updates
  • Automatic retries with exponential backoff
Practical reality: Most applications have other single points of failure (database, payment gateway, auth service) with similar availability profiles. Adding guaranteed availability for prompts while tolerating failures elsewhere provides minimal benefit.When to implement: Mission-critical systems (healthcare, finance, safety) with explicit zero-downtime requirements and comprehensive failure handling across all dependencies.

Option 1: Pre-Fetch Prompts on Startup

Fetch prompts during application initialization and exit if fetching fails:
Install dependencies:
Implementation:
Behavior:
  • ABV available at startup: Prompts cached, application starts normally
  • ABV unavailable at startup: Application exits with error code, orchestration system can retry or alert
Health checks: Container orchestration systems (Kubernetes, Docker Swarm) detect failed startup and prevent routing traffic to unhealthy instances.
Install dependencies:
Environment variables (.env):
Implementation:
Run:
Test:
Configure Kubernetes to detect pre-fetch failures:Deployment manifest (deployment.yaml):
Health endpoint implementation:
Behavior: If pre-fetch fails (app exits with code 1), Kubernetes:
  1. Detects container exit
  2. Doesn’t route traffic to failed pod
  3. Attempts restart with backoff
  4. Alerts if restart limit exceeded

Option 2: Fallback Prompts

Provide hardcoded fallback prompts when ABV is unreachable:
Text prompt with fallback:
Chat prompt with fallback:
Key properties:
  • prompt.is_fallback (bool): True if fallback prompt is being used
  • prompt.compile(**vars): Works identically for ABV and fallback prompts
Text prompt with fallback:
Chat prompt with fallback:
Key properties:
  • prompt.isFallback (boolean): true if fallback prompt is being used
  • prompt.compile(vars): Works identically for ABV and fallback prompts
Keep fallbacks in sync with production:
Monitor fallback usage:
Understand fallback limitations:
  • No metrics tracking: Fallback prompts aren’t linked to traces, so you lose version-specific metrics
  • No config: Fallback prompts don’t include config field (model parameters, tools, etc.)
  • Maintenance burden: Must keep fallbacks updated manually
  • Version mismatch risk: Fallback may not match current production prompt
When to use fallbacks: Only for truly mission-critical applications where any downtime is unacceptable. For most applications, pre-fetching or accepting occasional startup failures is simpler.

Comparing Approaches

Recommendation: Prefer pre-fetching for most mission-critical applications. It’s simpler and provides clearer failure modes. Use fallbacks only if your application absolutely must keep running during ABV outages.
Questions to ask:
  1. What’s the impact of a startup failure?
    • If deployment tools retry automatically, brief startup failures are harmless
    • If manual intervention is required, pre-fetching adds risk
  2. What’s your uptime requirement?
    • 99% (two nines): SDK caching is sufficient
    • 99.9% (three nines): Consider pre-fetching
    • 99.99% (four nines): Consider fallbacks or pre-fetching with multiple retries
  3. Do you have other single points of failure?
    • Database, auth service, payment gateway all have similar availability
    • If you tolerate those failures, why special-case prompts?
  4. Can you tolerate fallback degradation?
    • Fallback prompts may have lower quality than ABV-managed prompts
    • If quality is critical, pre-fetching (fail closed) is better
Most applications: Standard SDK caching provides sufficient availability without additional complexity.Mission-critical applications: Pre-fetch prompts at startup for clear failure modes.Absolute zero-downtime requirements: Use fallbacks, but understand the tradeoffs and maintenance burden.

Next Steps

Client-Side Caching

Understand how SDK caching provides resilience

Get Started with Prompts

Create and fetch prompts with ABV SDKs

Status Page

Monitor ABV’s real-time availability

Version Control

Manage prompt versions and deployments