Skip to main content
Back to Use cases

Conditional Routing, A/B & Canary

Route traffic by tenant, header, percentage, or feature flag; run canary and A/B tests without code changes.

Practical use cases

Concrete ways teams use Zerq for this scenario.

  • Send 5% of traffic to a new backend (canary)

    You deploy a new version of a service and want to test it with a small share of traffic. The workflow branches on a percentage (e.g. 5% to new, 95% to current). You watch metrics and errors for the canary; if all looks good, change the workflow to 100% new and publish—no code deploy.

  • Route by tenant or partner to different backends

    Enterprise partners hit a dedicated backend; free-tier users hit a shared one. The workflow branches on partner ID or header and calls the right backend. Same API path for everyone; you change routing by editing the workflow.

  • A/B test two response formats or backends

    Send half of requests to backend A and half to B (e.g. by header or random). Compare latency and errors in your metrics. When you pick a winner, point 100% to that backend in the workflow—again, no service redeploy.

Outcomes

  • Canary and A/B routing without redeploying services or gateway code.
  • Tenant- and partner-specific backends with a single API surface.
  • Quick rollback by editing the workflow (e.g. send 100% to stable backend).

How Zerq helps

  • Workflow branches: first node evaluates request (e.g. header X-Canary, or random/percentage); branch to different backend-call nodes so traffic splits without custom code.
  • Conditional routing by partner or product: each access level can be mapped to a different workflow or branch, so tenant-specific or tier-specific backends are easy.
  • Custom response node for fallback: if backend call fails or times out, branch to a fallback step (cached response, static response, or alternate backend).
  • Full audit and logs: every request logs which workflow and branch ran; Prometheus metrics by product/partner for canary comparison.
  • Change routing rules (percentages, headers, flags) in the workflow UI and publish; no gateway restart or redeploy.
For architects & evaluators (technical context, requirements)

Technical context

Teams need to route API traffic to different backends or versions based on context: tenant ID, API key, header (e.g. X-Version, X-Region), or a percentage (canary). Use cases include canary releases, A/B testing, tenant-specific backends, and feature flags. The routing logic should be configurable and auditable without redeploying the gateway or services.

Technical requirements

  • Route by request attributes: path, headers, query, identity, or partner.
  • Percentage-based routing (e.g. 5% to new backend, 95% to current) for canary.
  • Feature-flag or header-based routing for A/B tests or beta users.
  • Fallback when the selected backend is unavailable; optional retries.
  • Observability: which route was taken per request for analysis and rollback.

Request Enterprise Demo