Python — Backend APIs

API Gateway Patterns for Python Microservices

Direct answer

An API gateway for Python microservices should own the cross-cutting edge concerns — TLS termination, authentication, rate limiting, request routing, and correlation IDs — so individual FastAPI services stay focused on business logic. The main patterns are the off-the-shelf gateway (nginx, Kong, or a cloud provider's gateway) for pure edge duties, and the backend-for-frontend pattern where a thin Python service aggregates responses for a specific client. The classic failure mode is letting the gateway accumulate business logic until it becomes the new monolith.

Once a Python backend splits into services, every service either reimplements auth, rate limiting, and logging — or a gateway does it once for all of them. This piece covers the patterns I use to place a gateway in front of FastAPI microservices without creating a bottleneck or a second monolith.

Key facts, with sources

Postman's 2025 State of the API report, based on more than 5,700 developers and API professionals, found 83.2% of respondents adopting some level of an API-first approach. (Postman State of the API 2025)
The same Postman 2025 research found 65% of organizations now generate revenue directly from their API programs. (Postman State of the API 2025)
One in four developers (24%) now design APIs specifically for consumption by AI agents, while 89% use generative AI tools in their daily work. (Business Wire)
APIs make up 57% of the dynamic (non-cacheable) internet traffic processed by Cloudflare, and that share continues to grow. (Cloudflare)
Salt Security's 2024 State of API Security report found 95% of respondents experienced API security problems in production, with security incidents more than doubling year over year from 17% to 37% of organizations. (Salt Security)

What belongs in the gateway, and what never should

The gateway's job is everything that is true for every request regardless of which service handles it: TLS termination, authentication token validation, coarse rate limiting, request size caps, routing, compression, and attaching a correlation ID. These are mechanical, service-agnostic, and change rarely — perfect edge material.

What must not live there: business rules, data transformation beyond header manipulation, and anything requiring a database lookup per request beyond auth. I have audited systems where the gateway validated order states and computed discounts, and every product change required a gateway deploy that risked all traffic. The test I apply: if a rule would change because the product changed, it belongs in a service, not the edge.

Choosing between off-the-shelf and hand-rolled

For pure edge duties, do not write Python. nginx, Envoy, Kong, Traefik, and the managed gateways from cloud providers handle TLS, routing, and rate limiting with performance and battle-testing no hand-rolled FastAPI proxy will match. A Python gateway also puts an interpreter and event loop in the path of every byte of traffic, making it your scaling ceiling.

Where a custom Python layer does make sense is one level behind the edge, as an aggregation tier — which is really the BFF pattern rather than a gateway. My typical stack is boring: a managed load balancer or nginx at the true edge doing TLS and routing, then FastAPI services behind it, with a BFF only if clients need response composition.

The backend-for-frontend as a gateway variant

When a mobile app's screens need data from three services, someone has to do the joining. Making the client do it means three round trips over a cellular radio. Making a generic gateway do it violates the no-business-logic rule. The answer is a backend-for-frontend: a small FastAPI service owned by the client team that exposes screen-shaped endpoints and fans out to internal services concurrently with an async HTTP client.

A BFF differs from a gateway in ownership and scope. It serves exactly one client type, changes when that client's screens change, and is allowed to contain presentation logic — choosing fields, merging objects, formatting. Internal services keep clean generic APIs; the BFF absorbs the client-specific mess. With separate mobile and web BFFs, neither team blocks the other.

Authentication at the edge, trust inside

The pattern that keeps auth from being reimplemented in every service: the gateway validates the bearer token — signature, expiry, revocation — once, then forwards the request with trusted identity headers such as the user ID and scopes. Internal services read those headers and skip token cryptography entirely.

This only works if the trust boundary is real. Internal services must be unreachable except through the gateway — enforced by network policy, not convention — and should reject requests missing the identity headers rather than treating them as anonymous. In audits, the scariest finding is an internal service accidentally exposed to the internet that trusts identity headers anyone can forge. If services can be reached directly, use mutual TLS or verify a gateway-signed token instead of bare headers.

Observability: the gateway as your source of truth

The gateway sees every request, which makes it the natural place to establish the observability spine. It should generate a correlation ID for each inbound request, attach it as a header, and every Python service should propagate it into logs and downstream calls. When a user reports a failure, one ID pulls the full request story across services.

Gateway access logs also give you the honest latency picture — including time spent in queues and connection setup that service-level metrics miss. I alert on gateway-measured p95 latency and 5xx rates per route, because that is what users actually experienced. Service dashboards then explain why, not whether, something is wrong. Without gateway-level truth, every incident begins with services blaming each other's metrics.

When to hire senior help

Bring in senior backend help when you are defining the public contract of your API (auth model, versioning, rate limits), because those decisions are nearly impossible to change once partners integrate. It is also warranted when incidents like timeout cascades, N+1 query storms, or authorization bugs start appearing, since these are pattern problems a senior engineer has usually fixed many times before. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships Python — Backend APIs projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

✕Shipping list endpoints without pagination or rate limiting, then having one integration partner's bulk pull take down the database
✕Launching with no versioning strategy, so the first breaking schema change strands mobile apps that cannot be force-updated
✕Missing per-object authorization checks (broken object-level authorization), letting any authenticated user read other tenants' records by iterating IDs
✕Treating internal APIs as trusted and undocumented, then exposing them to partners or frontends later without adding auth, quotas, or contracts

Frequently asked questions

Do I need an API gateway if I only have two or three services?

You need something doing TLS, routing, and auth in one place, but it can be as simple as nginx or your cloud load balancer plus a shared auth dependency in FastAPI. Dedicated gateway products earn their complexity when you have many services, multiple client types, per-consumer rate limits, or a public API program. Start minimal and promote the edge layer as needs appear.

Should I build my API gateway in Python with FastAPI?

Not for pure edge duties like TLS, routing, and rate limiting — proven proxies such as nginx, Envoy, or managed cloud gateways do that faster and more reliably than a hand-rolled Python proxy. FastAPI is the right tool one layer behind the edge, as a backend-for-frontend that aggregates several service responses into screen-shaped endpoints for a specific client.

How do microservices behind a gateway handle authentication?

The gateway validates the token once — signature, expiry, revocation — and forwards trusted identity headers like user ID and scopes to internal services, which skip token validation entirely. This requires that services are network-isolated so only the gateway can reach them; otherwise forged headers become a critical vulnerability. If direct access is possible, add mutual TLS or gateway-signed internal tokens.

Is Python fast enough for our backend API?

For the vast majority of products, yes: async Python frameworks handle thousands of requests per second per instance, and real-world latency is usually dominated by database queries and network calls, not language speed. Teams typically only outgrow Python at extreme throughput, and even then usually rewrite specific hot services rather than the whole backend.

How much API security do we need at MVP stage?

At minimum: authentication on every endpoint, per-object authorization checks, rate limiting, and input validation. Salt Security found 95% of organizations hit API security problems in production and incidents doubled year over year, so retrofitting security after a breach is far costlier than building these four basics in from day one.

REST or GraphQL for a new product?

REST with an OpenAPI spec remains the default for most backends because tooling, caching, and hiring are simpler. GraphQL earns its complexity when many differently shaped clients consume the same data graph. Starting with REST and adding GraphQL later where needed is a common, low-risk path.

Bottom line: Dhairya Senjaliya ships Python — Backend APIs projects worldwide. Book a scoping call at https://dhairyasenjaliya.com/#book-call.