Architecture pattern · API architecture

Enterprise API gateway architecture, from edge routing to GraphQL federation.

Put one controlled front door in front of microservices, legacy systems and partner APIs: consistent security and rate limits at the edge, and one typed graph for clients.

Book Gateway Audit Back to Platform Overview

Design targets · not measured results from past client work

Target · Gateway Overhead< 50ms

Latency budget for the gateway layer itself (routing, auth check, rate-limit check), excluding upstream service time. Measured per route, not assumed.

Target · Contract Guard100%

Every schema change passes composition and breaking-change checks in CI before it can merge.

Target · Query Efficiency10×

Fewer client round trips for composite screens: one query through the router instead of many calls.

Target · Policy Drift0%

One set of security and rate-limit policies applied at the edge, so public and internal routes follow the same rules.

The short answer

What is an API gateway?

An API gateway is a single entry point between clients and backend services. It routes each request to the right service and can take on shared work, such as authentication, TLS, rate limiting, logging and caching, so individual services do not each have to. Microsoft describes three common gateway patterns: routing, aggregation and offloading. A GraphQL router is a related layer that goes a step further and composes data from several services into one typed graph.

Routing

The gateway acts as a reverse proxy and sends client requests to different services behind a single endpoint, so clients do not need to know where each service lives.

Aggregation

The gateway, or a GraphQL router, combines several backend calls into one response, which reduces chattiness between clients and services.

Offloading

Cross-cutting features such as TLS termination, authentication, rate limiting, logging and a web application firewall are handled once at the gateway instead of in every service.

Robral designs and builds API gateway layers for enterprises: the edge gateway, a federated GraphQL layer where it fits, adapters that protect legacy and SAP backends, rate limiting and tracing, delivered first as a 14-day proof of concept.

Layered design

Three layers. One controlled edge.

An edge gateway for entry and policy, a federation layer for clients, and adapters that protect the systems behind them.

Subgraph Federation

GraphQL Federation & Supergraphs

Compose independent domain subgraphs into one supergraph that clients query. Each team owns its subgraph, and a router plans each query across them. Federation fits when several teams own parts of the data; it adds governance work, so it is not the default for every system.

Apollo Federation 2 schema composition
Subgraphs owned by the domain teams that know the data
Entities shared across subgraphs through @key
Router-level caching and query limits

Edge Runtime

Edge Gateways, Routing & gRPC

Terminate client traffic at an edge gateway that routes requests, checks identity, applies rate limits and logs every call. Translate between protocols where clients and services differ, for example gRPC-Web to gRPC, and shift traffic gradually with weighted routing.

Layer-7 routing behind a single public endpoint
Weighted canary routing (for example 90/10) with defined rollback thresholds
Protocol translation between client and service formats
Connection reuse and upstream pooling tuned per service

System Modernisation

Legacy Wrappers & ERP Adapters

Expose clean REST or GraphQL contracts in front of SAP, mainframes and SOAP services without changing them. Adapters translate protocols, cache reads and buffer bursts so the legacy system sees a calm, predictable load.

XML/SOAP to JSON or gRPC translation in the adapter layer
Request buffering and queueing during traffic surges
Read-through caching to shield the legacy backend
Access through the legacy system’s own interfaces, not direct table changes

Choosing a gateway

Which gateway for which situation?

There is no single best gateway. The right choice follows your cloud, your clients and who runs it. This table covers the options we most often assess.

Situation	Typical fit	Why it fits	Watch out for
One public front door for many services; shared auth, limits and logging	A dedicated API gateway (gateway routing plus offloading)	Handles routing, TLS, authentication, rate limiting and logging once, in front of every service.	Keep business logic out of it, and run it redundantly: every request passes through it.
Clients need data from several services in one request; domain teams own the schemas	GraphQL federation with a router (for example Apollo GraphOS Router)	Subgraphs owned by each team are composed into one supergraph that clients query.	Not a silver bullet. Needs schema governance, and the router’s capacity limits how many subgraphs are practical.
AWS-native workloads	Amazon API Gateway: REST API or HTTP API	AWS recommends REST APIs when you need API keys, per-client throttling, request validation, AWS WAF or private endpoints. HTTP APIs are leaner and lower priced.	HTTP APIs do not support API keys, per-client rate limiting or AWS WAF, so check features before choosing.
Heavy gRPC traffic, edge protocol translation, custom rate-limit logic	An Envoy-based gateway	Envoy integrates with a global gRPC rate limit service and supports local token-bucket limits in each proxy.	More to operate and configure than a managed gateway. You own upgrades and tuning.
Self-managed gateway with plugins, on Kubernetes or VMs	Kong Gateway	Supports traditional (database), hybrid (control plane and data planes) and DB-less (declarative file) modes. In hybrid mode, data planes keep their last known configuration if the control plane goes offline.	Plugins that need a database only work in traditional mode. Pick the topology deliberately.
Azure estate	Azure API Management, often with Application Gateway or Front Door	A managed service for publishing APIs with rate limiting, IP restrictions and Microsoft Entra ID authentication.	API Management does not load balance, so pair it with a load balancer such as Application Gateway.
Service-to-service traffic inside a Kubernetes cluster	A service mesh ingress gateway	Fits mesh-native traffic, for example the managed Istio ingress on AKS.	Microsoft notes mesh ingress gateways typically have weaker capabilities than dedicated API gateways for WAF, API productization, request transformation and global routing.

Platform features change. Check the vendor’s current documentation before you decide. References are listed below.

Key engineering capabilities

The gateway toolchain.

Core building blocks we include in a gateway engagement.

Distributed Rate Limiting & Token Buckets

Limits per client, per tenant and per expensive route. A local token bucket in each gateway instance absorbs bursts cheaply, and a shared limit service keeps the total consistent across instances. Rejected requests get a clear 429 response.

Token BucketShared Limit ServicePer-Tenant QuotasRedis

Schema Validation & Breaking-Change Guards

Composition and breaking-change checks run in CI for GraphQL and OpenAPI schemas, so a contract change is caught before it reaches mobile and web clients.

Schema RegistryCI ChecksOpenAPI 3.1Apollo Rover

Unified Security at the Edge

One inspection point for token validation, WAF rules, CORS and mutual TLS. Edge checks complement, but do not replace, authorization inside each service.

JWT ValidationWAFmTLSCORS

Telemetry & Distributed Tracing

OpenTelemetry traces follow a request across the gateway, auth steps and legacy adapters, with W3C Trace Context propagated end to end, so a slow request can be traced to the hop that caused it.

OpenTelemetryW3C Trace Contextp99 ProfilingError Budgets

Engineering notes

What a safe gateway rollout looks like.

Choosing the gateway is the easy part. The discipline is in contracts, limits, and where each security check lives.

Two subgraphs, one entity (illustrative, Apollo Federation 2)

# products subgraph: owns Product
extend schema
  @link(url: "https://specs.apollo.dev/federation/v2.0",
        import: ["@key", "@shareable"])

type Product @key(fields: "id") {
  id: ID!
  name: String!
  price: Money @shareable
}

# reviews subgraph: references Product, owns Review
extend schema
  @link(url: "https://specs.apollo.dev/federation/v2.0",
        import: ["@key"])

type Product @key(fields: "id", resolvable: false) { id: ID! }
type Review  { id: ID!  body: String!  product: Product! }
type Query   { reviewsFor(productId: ID!): [Review!]! }

The reviews subgraph only needs the product id, so it declares a stub with resolvable: false. The router joins the two when a client asks for a product and its reviews in one query. Run schema composition and breaking-change checks in CI so no team can merge a change that breaks the supergraph.

Gateway readiness checklist

Every public route is registered in one place with an owner, an authentication method and a rate-limit tier.
Authentication happens at the edge, and each service still authorizes access to its own data. Broken object-level and function-level authorization are OWASP API1 and API5.
Rate limits apply per client or tenant and on expensive routes. Combine a local limit in each instance with a shared limit so totals stay consistent.
GraphQL has depth and cost limits and per-request timeouts. OWASP lists unrestricted resource consumption as API4.
Timeouts, retries and circuit breaking are set per upstream. Retried writes are idempotent.
Legacy backends sit behind adapters with caching and queueing, and have been load tested at expected peak.
Trace context is propagated through the gateway, adapters and services.
Gateway configuration lives in version control, and routing changes roll out as canaries with a tested rollback.
The gateway runs redundantly, with alerts on latency, error rate and saturation.

Common mistakes

Where API gateway projects go wrong.

Six failure patterns we design against from the first week.

Business logic in the gateway

A gateway that grows rules about pricing, eligibility or workflows becomes a second monolith that every team must change. Keep it to routing, security and shared policy.

Thin gatewayOwnershipPolicy only

Gateway as single point of failure

Every request passes through it, so it needs redundancy, capacity planning and its own monitoring. A single instance is a single outage.

High availabilityCapacityAlerting

Federating too soon

Federation is not a silver bullet. With one or two teams, a simple gateway may be enough, and the router’s ability to process schema metadata limits how many subgraphs are practical.

Start smallGovernanceSubgraph count

Authorization only at the edge

An edge check cannot know whether this user may see that record. Object-level and function-level authorization belong in the services that own the data.

OWASP API1OWASP API5Defense in depth

Per-instance rate limits

A limit counted separately in each gateway instance lets a client exceed the intended total as you scale out. Add a shared limit for the numbers that matter.

Shared limitsBurst control429 handling

Silent contract drift

Without checks in CI, a renamed field breaks clients that nobody told. Gate schema changes before merge and version deliberately.

Breaking-change checksSchema registryVersioning

What you receive

A working gateway sandbox. In 14 days.

Live Gateway Sandbox

A gateway and federation router deployed in a dedicated environment, serving one real slice of your APIs behind a single endpoint.

Edge Operations Console

A dashboard for route latency, request traces, per-consumer rate-limit usage and schema contract check results.

Terraform & OpenAPI Toolchain

Infrastructure as code with schema CI gates, rate-limit policies and adapter configuration, ready for your engineers to run.

Not slides. Not a proposal. A live gateway serving a real slice of your APIs.

Choosing a partner

How to choose an API gateway partner.

Six questions to ask any firm, including us, before you commit.

Platform reasoning

Ask why they would pick one gateway over another for your estate. Look for trade-offs tied to your cloud, team and clients, and honesty about when a simpler option is enough.

Red flag: one platform for every client

Contract management

Ask how schema changes are reviewed and released. Look for composition and breaking-change checks in CI, ownership per subgraph and a versioning policy.

Red flag: no contract tests

Legacy protection

Ask how the legacy system is shielded. Look for adapters, caching, queueing and a load test at expected peak.

Red flag: "we call it directly"

Security model

Ask where each check lives. Look for edge authentication plus per-service authorization, resource limits and awareness of the OWASP API Top 10.

Red flag: "the gateway handles security"

Observability

Ask how you will find a slow request. Look for distributed tracing across hops, per-route latency and error budgets.

Red flag: logs only

Ownership and handover

Ask what you own at the end and who runs it. Look for infrastructure as code, runbooks and training handed over, with acceptance criteria agreed up front.

Red flag: black-box delivery

Questions and answers

API gateway: common questions.

What does an API gateway do?

An API gateway is a single entry point for client requests. It routes each request to the right backend service, and can handle shared concerns once: TLS termination, authentication, rate limiting, logging, caching and a web application firewall. Microsoft groups these roles into gateway routing, gateway aggregation and gateway offloading.

Do I need both an API gateway and GraphQL federation?

They solve different problems and are often used together. A gateway controls the entry point: security, rate limits and routing. Federation lets several teams contribute subgraphs to one GraphQL schema, with a router planning queries across them. If one team owns the data and clients make few calls, a gateway alone may be enough.

What is the difference between REST APIs and HTTP APIs in Amazon API Gateway?

AWS says REST APIs support more features and HTTP APIs are designed with minimal features so they can cost less. Choose a REST API if you need API keys, per-client throttling, request validation, AWS WAF or private endpoints. Choose an HTTP API if you do not need those features.

How does rate limiting work across several gateway instances?

A local limit, such as a token bucket in each instance, handles bursts without a network call. A global limit uses a shared rate limit service so the total stays consistent across instances. Envoy documents both, and notes that they can run together: a coarse local limit first, then a finer global limit.

Can an API gateway fix a slow legacy system?

Not by itself. A gateway or adapter can cache reads, queue bursts and translate protocols, which reduces the load the legacy system sees. It cannot make slow queries inside the legacy system faster, so we measure the real bottleneck first.

Which API security risks can a gateway help with?

A gateway is well placed to help with authentication, resource limits and keeping an inventory of exposed routes. The OWASP API Security Top 10 (2023) also lists risks such as broken object-level authorization (API1) and broken function-level authorization (API5). Those have to be enforced in the services that own the data, not at the edge alone.

How long does it take to put a gateway in front of existing APIs?

It depends on how many APIs, how consistent they are and how much legacy integration is involved. A proof of concept on one slice of your APIs is the quickest way to get a realistic estimate, and we deliver that as a 14-day sandbox.

References

Last reviewed: October 2026

Architectural lineage

View all engineering patterns

Unify your APIs

Ready to put one controlled edge in front of your APIs?

Work with our principal architects to blueprint a gateway and federation layer for your exact service landscape.

Start a POC Schedule Architecture Review