Few pairs of building blocks get mixed up as often as the API gateway and API orchestration. Both sit between consumers and services, both forward calls, and the vendors' product brochures overlap in their promises. The objection "we already have a gateway, why would we need orchestration on top?" is understandable for that reason, and it deserves a reasoned answer.
A gateway is in place, the license paid, and now the next architecture building block shows up on the list, one that also has something to do with connecting APIs. From the business side, that sounds like the same tool bought twice. In reality, gateway and orchestration answer two different questions, and neither can take over the other’s job without neglecting its own.
An API gateway is the central entry point of an API landscape and handles cross-cutting concerns such as routing, authentication, rate limiting, and logging for individual calls. API orchestration, in contrast, coordinates multiple calls into one business flow, including order, data handoffs, and failure handling. The gateway controls traffic, the orchestration controls flows. The two complement each other and do not replace one another.
What an API gateway does
A gateway works at the level of the individual call. A request arrives, the gateway checks the token, applies the rate limit, writes a log entry, and forwards the request to the responsible service. The response takes the same path back. All of that happens per request, in milliseconds, and without the gateway understanding what the call means in business terms.
That restriction is no shortcoming. It is the design principle. The gateway bundles the jobs that are identical for every API and that no team should build twice. Authentication, authorization, TLS termination, rate limiting, request logging, and routing by path or header are exactly such cross-cutting concerns. They belong at the edge of the architecture, at a spot every call passes through anyway.
What the gateway knows at no point is the connection between calls. Whether the request to the payment service belongs to the same order as the request to the inventory service two seconds earlier is something it does not know and does not need to know. To the gateway, every request is a self-contained occurrence.
What an orchestration does
An orchestration starts exactly where the gateway’s knowledge ends, at the connection. It knows the business transaction that stretches across several calls. In the order example, it knows that inventory gets reserved first, that the payment needs the result of that reservation, and that shipping may only start once both have succeeded. It holds the transaction’s state, passes data from step to step, and decides on failure which steps get rolled back.
That puts the orchestration on a different time scale, with different knowledge. An orchestrated transaction can take seconds, or days when it waits for an approval. It has a beginning, an end, and a state in between. None of that exists at the gateway level. The fundamentals of this flow control are covered in the overview of API orchestration, and the line to the event-driven variant is drawn in Orchestration vs. choreography.
A layer model makes the boundary visible
It helps to picture three layers a call travels through. At the edge sits the gateway, handling each request on its own. Behind it, where needed, sits the orchestration, connecting several requests into one transaction. Below that, the business services do their work, executing individual operations without knowing the overall flow.
Each layer holds its own knowledge. The gateway knows identities, limits, and routes. The orchestration knows flows, sequences, and compensations. The services know their domain. Trouble reliably starts when knowledge drifts into the wrong layer, when the gateway starts knowing sequences, say, or when a business service enforces rate limits on the side.
| What the gateway does | What the gateway does not do |
|---|---|
| Authentication and authorization per request | Hold the state of a business transaction |
| Routing, rate limiting, TLS termination | Control the order of multiple calls |
| Request logging and traffic metrics | Pass data from one call into the next |
| Protect services from overload and abuse | Compensate failed steps |
| Light touch-ups such as header rewriting | Make business decisions inside a flow |
The right column is no list of missing features that a better gateway will ship someday. It describes jobs that require different knowledge and a different lifecycle, which is why they belong in a different layer.
The difference becomes obvious when you put the two configurations side by side. A gateway route defines where a single request goes, under which conditions. An orchestration step describes what comes after it and which data flows there.
route:
path: /orders
methods: [POST]
upstream: order-service
rateLimit: 100/min
auth: jwt
# Orchestration step: part of a flow with data handoffs
- stepId: authorizePayment
operationId: authorizePayment
parameters:
- name: reservationId
value: $steps.reserveStock.outputs.reservationId
onFailure:
- type: goto
stepId: releaseStock
The vocabulary alone gives the layer away. The route talks about paths, limits, and upstreams, in other words about traffic. The step, in contrast, talks about predecessors, data handoffs, and failure paths, in other words about flows. Spot vocabulary from the second world inside your gateway configuration, and the mix-up has already moved in.
Operations and ownership split as well
Organizationally, the two building blocks live different lives too. A gateway is infrastructure. It usually belongs to a platform team, changes rarely, and counts as a critical component whose outage hits every API at once. Changes to it run through accordingly careful processes, and rightly so.
An orchestrated flow is business logic. It belongs to the team that owns the business process, and it changes whenever the process changes, which is comparatively often. A new step in the onboarding, a reordered sequence in the order flow, an additional check in the credit application, all of these are business changes that have to ship fast and without a platform ticket.
These different rates of change are an argument for the separation in their own right. Move flow logic into the gateway and it inherits the gateway’s cautious change process, making business changes artificially slow. A gateway that absorbs weekly business changes, in turn, would lose its role as stable, predictable infrastructure. Each layer needs the change cadence that matches its content.
A side note on the backend-for-frontend, which belongs in this discussion. A backend-for-frontend bundles calls for exactly one type of consumer, the mobile app, say, and is allowed to aggregate for it. That makes it neither gateway nor orchestration, a consumer-specific facade, plainly. The moment a backend-for-frontend starts driving write chains with compensation, the same boundary applies as for the gateway, and the flow logic deserves a layer of its own.
Where the mix-up comes from
That the two blocks land in one bucket so often has understandable reasons. The first lies in the products themselves. Many gateways offer features that point toward flow control, response aggregation that returns the results of several services bundled into one call, say, or small request pipelines with conditional forwarding. Features like that are handy for reads and perfectly legitimate. They look like orchestration, though, and that is exactly how the impression forms that the gateway could absorb the role along the way.
The second reason is language. Both blocks get described as "the layer between consumers and services", and in architecture diagrams they end up as similar-looking boxes in similar places. Whoever knows the diagrams without knowing the operational reality will treat them as interchangeable.
The third reason is the most honest one. A gateway is usually already there, paid for, and operated. The temptation to put a new requirement into the existing component, rather than introduce another one, is human and budget-driven. In the short run it saves a building block. In the long run it shifts flow logic into a place that was neither designed nor easy to test for it.
In a project at a bank, we found the logic of a credit application inside the gateway’s routing rules, grown over two years from small, individually harmless extensions. The rules called three services one after another and evaluated intermediate results. That logic saw practically no testing, because the gateway configuration lived outside the usual CI pipelines, and every change needed the central platform team. After the flow logic moved into a dedicated orchestration service, the turnaround for changes dropped from weeks to days, and the gateway went back to its actual job.
When the gateway orchestrates
The pattern from that observation deserves a name, because it repeats across industries. A gateway starts driving flows and slowly becomes an orchestrator without an orchestrator’s properties. It lacks the state handling for long-running transactions, the compensation logic, the testability, and usually the ownership too, because the gateway belongs to a platform team and the flow to a business unit.
Three warning signs show the drift has begun.
- Call chains appear in the gateway configuration where one backend’s result decides the forwarding to the next.
- Changes to a business flow require platform-team tickets, even though no cross-cutting concern is involved.
- The gateway configuration grows faster than the number of APIs, because it absorbs logic that has nothing to do with controlling traffic.
Spotting one of these signs is no reason to panic, and it is reason enough to stop the trend before the configuration becomes an untested annex of the business logic. The flow logic belongs in a layer of its own, whether as code in a service or as a declarative description, with the workflow specification Arazzo, say, which What is Arazzo introduces.
The gray zone of aggregation
In fairness, there is a zone where the line genuinely blurs. Pure read aggregation, where one call collects data from three services and returns it bundled, is the mildest form of multi-call coordination. There is no order dependency, no state, and nothing to compensate, because nothing changes. A gateway or a backend-for-frontend can take that job without any problem arising.
The line is drawn at the first writing step. As soon as one call in the chain changes data and a later step depends on that result, real orchestration begins, with everything it entails. Where exactly aggregation ends and orchestration begins is what Composition digs into, with examples and a decision matrix.
A quick test question for the assignment is whether anything would need cleaning up after an abort midway. If yes, you are looking at orchestration, and the logic does not belong in the gateway. If no, it is aggregation, and the gateway may take it.
Where API management and the portal come in
The picture is completed by two more terms that tend to hover in the same conversation. API management is the discipline around the API lifecycle, covering versioning, governance rules, access control, and monetization. The gateway is merely that discipline’s runtime tool in the data path. A developer portal, in turn, makes the API landscape usable for people, with catalog, documentation, and self-service onboarding, a topic that API developer portal covers in depth.
Orchestration slots into this picture as a fourth, distinct level. It is neither runtime infrastructure like the gateway, nor a governance discipline like management, nor a human interface like the portal. It is the level where individual APIs become business flows. The connection to the portal gets interesting at a spot that is easy to miss. Once flows are described as declarative workflows, they can be published in the same catalog as the APIs themselves, and consumers then find more than the twelve endpoints. They find the order in which the endpoints belong together.
For governance owners, the concrete takeaway is that orchestration descriptions should follow the same rules as API specs. They need an owner, a version, a review on change, and a place in the catalog. Teams that already maintain their OpenAPI documents with discipline have those processes in place and only extend them to one more kind of artifact.
Working together instead of either-or
In the target picture, both blocks work together, each in its layer. A consumer’s call first passes the gateway, which verifies identity and applies limits. Behind it, the orchestration picks up the transaction, calls the business services in the right order, and for each individual call relies on the very infrastructure the gateway provides. Traffic control and flow control complement each other because they answer different questions.
The answer to the objection from the start is rarely "buy another product", by the way. The first orchestrated flow usually comes to life as a lean dedicated service next to the gateway, described in a workflow spec, operated by the team that owns the business process. The gateway stays what it is, and that is exactly the point.
Check your own gateway configuration for call chains that evaluate intermediate results. Every one of those spots is a candidate for explicit orchestration, and a risk for as long as it stays where it is.