Skip to main content
Back to Use cases

Error Handling, Retries & Fallbacks

Retry with backoff, fallback to cache or alternate backend, and return consistent error shapes—all defined in workflows.

Practical use cases

Concrete ways teams use Zerq for this scenario.

  • Retry a flaky backend before failing the client

    The workflow calls your backend; if it returns 503 or times out, the workflow retries with backoff (e.g. 2–3 times). Only after exhaustion do you return an error to the client. You tune retry count and delay in the workflow without touching the backend.

  • Fall back to cache or alternate when primary is down

    On final failure after retries, branch to a read-from-cache step or an alternate backend (e.g. read replica or simplified response). The client gets a valid response instead of a 5xx when possible.

  • Return the same error shape for every failure type

    Whether the failure is timeout, 502, or quota exceeded, the workflow can return a consistent JSON error (e.g. RFC 7807 or your standard) so clients handle one format. Easier to document and integrate.

Outcomes

  • Resilient APIs with retries and fallbacks defined in one place.
  • Consistent error responses and behavior across products.
  • Easier SLO and incident response with clear visibility into retries and fallbacks.

How Zerq helps

  • Workflow designer: a backend-call step can be followed by a branch on status or error; on 5xx or timeout, route to a retry step or fallback (e.g. call backup backend or custom response node with 503 + standard JSON).
  • Reference previous step data: use the first call’s response in a fallback (e.g. return stale cache keyed by request); optional code node for retry/backoff logic if needed.
  • Custom response nodes for error bodies: return the same error shape (e.g. RFC 7807 or your standard) for gateway-level errors, quota exceeded, or backend unavailable.
  • Duplicate request protection and optional response caching: reduce redundant calls and support cache-as-fallback when backend is down.
  • Structured logs and metrics: log retries and fallback usage; Prometheus for success/retry/fallback counts so you can set alerts and SLOs.
For architects & evaluators (technical context, requirements)

Technical context

Backends fail, timeout, or return transient errors. Clients expect consistent error formats (RFC 7807, custom envelopes) and resilient behavior (retries, fallbacks). Implementing retry and fallback in each service is repetitive and often inconsistent. A workflow layer can: retry a backend call with backoff, on final failure branch to a cache or alternate backend, and return a standardized error response—all configurable per API or product.

Technical requirements

  • Retry failed or timed-out backend calls with configurable attempts and backoff.
  • Fallback path: on failure, call alternate backend or return cached/static response.
  • Consistent error responses (status, body shape) across APIs for client handling.
  • Circuit-breaker or degradation behavior optional (e.g. after N failures, use fallback for a period).
  • Visibility into retries and fallbacks for debugging and SLO reporting.

Request Enterprise Demo