Design gateway workflows without shipping another microservice
Use visual workflows for routing, branching, and responses at the edge—so policy changes don’t wait on a backend deploy cycle.
- workflows
- platform
- operations
When every policy tweak requires a ticket, a code review, and a deploy, latency to learn kills iteration. Gateway workflows exist so platform teams can move fast without inventing a new service for every “if this, then that” rule.
What “workflow” means here
In Zerq, workflows are visual graphs you attach to the request path. Think of them as programmable edge logic that can:
- Route traffic based on headers, scopes, partner identity, or lightweight context.
- Branch when you need different behavior for different outcomes.
- Shape responses when you need a consistent error envelope or transformation before the upstream even sees the request.
That maps directly to the Workflow designer capability—see Capabilities for the full list.
A concrete pattern: scope checks before upstream spend
A common pattern is to validate authorization context early:
- Parse the incoming token/session context the same way your apps do.
- If the caller lacks the right scopes, return a clear client error without hammering the origin service.
- If the caller is allowed, optionally enrich the request (headers, correlation IDs) and forward.
When to reach for a code node
Visual nodes cover most cross-cutting rules. A code node is useful when you need a small, controlled piece of logic that is still owned by the platform team—but keep it narrow:
Tip: If the workflow starts looking like a full domain service, that is a signal to move core business rules back to the owning team’s service—and keep the gateway workflow focused on edge policy and consistency.
Operability: workflows are part of your audit story
Because workflows live next to the gateway, changes are easier to review than ad-hoc middleware spread across repos. Pair this with Observability so you can prove what path a request took when incidents happen.
Next step: If you are standardizing error formats and scope checks across dozens of routes, pilot one high-traffic API product on workflows and measure time to change vs your old deploy path.