Y

Right now, your developers are probably handling all of that inside the application code itself. It works. Until it doesn't.

An API gateway is the piece of infrastructure that sits in front of your backend services and handles all of that in one place. Understanding what it does — and when you actually need one — will help you ask the right questions before your team builds the wrong thing.

What an API gateway actually does

Think of it as the front door to your entire backend.

Every request coming into your system — from your mobile app, your web frontend, a partner's integration, an internal admin tool — goes through the gateway first. The gateway checks whether the request is allowed, decides where to send it, and can transform or enrich it before it ever reaches your actual services.

The key functions it handles: authentication and authorisation (is this user allowed to do this?), rate limiting (is this user making too many requests?), request routing (which backend service should handle this?), logging (what happened and when?), and sometimes response caching.

Without a gateway, every single one of your backend services has to implement all of that independently. Your user service has its own auth logic. Your payments service has its own rate limiter. Your notifications service does its own logging. They all do it slightly differently. When something goes wrong, you debug five places instead of one.

The five jobs it handles that your team is probably doing by hand

Authentication in one place. Instead of every service verifying tokens individually, the gateway verifies once and passes the request through. One vulnerability to patch, not five.

Rate limiting. If a user hammers your API — intentionally or not — the gateway cuts them off before the traffic hits your database. This matters a lot during high-traffic moments. Lebaran, Harbolnas, a viral post: your backend sees a spike, your gateway absorbs it.

Request routing. As your product grows, different parts of it get broken into separate services. The gateway decides which service gets which request. Your mobile app doesn't need to know your internal service topology.

Logging and observability. Every request, every response, every error — captured in one place. When your CTO asks "what happened at 2am on Sunday?", there's a single place to look. This is significantly harder when logging lives inside twenty different services.

Transformations. Sometimes your mobile app needs a different response shape than your web app. The gateway can handle that translation so your backend stays clean.

When you actually need one

Not on day one. If you have a single backend service and one frontend, a gateway is overhead you don't need yet.

The signal to pay attention to: when you have more than one client talking to your backend, or when more than one backend service is involved. If your mobile app and your web app both talk to the same API, you already have a routing problem that a gateway solves cleanly.

A more specific trigger: when your developers start copy-pasting authentication code between services, that's technical debt accumulating fast. A gateway stops that pattern before it spreads.

The [→ Read: What Is an API?] post covers the underlying concept if you want the foundation first. And if you're thinking about how this fits into a broader architecture decision, the [→ Read: What Is Software Architecture?] guide is worth fifteen minutes.

The part most founders get wrong

Waiting until it's painful.

The common pattern: team builds without a gateway, product grows, now there are six services all doing auth differently, rate limiting is inconsistent, and adding the gateway becomes a multi-month project with migration risk.

Adding a gateway early — when there's only one or two services — takes days, not months. The configuration is simple. The migration risk is low. The team builds good habits from the start.

The other mistake: treating the gateway as a magic solution for a badly designed API. It isn't. If your [→ Read: API design for high-throughput systems] is fundamentally broken, putting a gateway in front of it delays the pain but doesn't fix the problem. The gateway handles cross-cutting concerns. It doesn't fix bad data models or leaky abstractions.

Real-world example

A fintech startup running a buy-now-pay-later product in Indonesia. Three clients: a merchant app, a consumer app, and a reconciliation dashboard used by the finance team.

Initially, all three talked directly to a single backend service. Auth logic was embedded in route handlers. Rate limiting didn't exist. The finance dashboard had no access restrictions beyond "is the user logged in."

When they brought on a third-party merchant integration, the cracks showed. The integration needed different authentication (API keys, not JWTs). The backend had no clean way to handle it. The team spent three weeks building a bespoke solution that half-worked.

They added Kong as a gateway. Auth moved out of application code. The third-party integration got its own API key policy. Rate limiting was configured in thirty minutes. The finance dashboard got IP-based access restrictions without touching application code.

Total time: two weeks. Time saved on every subsequent integration: significant.

FAQ

Q: What's the difference between an API gateway and a load balancer?

A: A load balancer distributes traffic across multiple instances of the same service to prevent any one instance from being overwhelmed. An API gateway routes traffic to different services based on what the request is asking for, and handles auth, rate limiting, and logging along the way. Most production systems use both.

Q: Do I need to build an API gateway myself?

A: No. There are good options at every budget. Kong, AWS API Gateway, Nginx with plugins, and Traefik are all used in production. The right choice depends on your infrastructure and team familiarity. Building your own is almost never the right call.

Q: Can an API gateway slow down my application?

A: Yes, it adds a network hop. In practice, the latency overhead is single-digit milliseconds for a well-configured gateway — negligible compared to database queries and external API calls. The operational benefits far outweigh the latency cost.

Q: What is an API gateway in simple terms?

A: It's the single entry point to your backend. Every request goes through it before reaching any of your services. It checks who's asking, whether they're allowed, how many times they've asked recently, and where to send the request.

Q: Should early-stage startups bother with an API gateway?

A: If you have one frontend talking to one backend, probably not yet. Once you have multiple clients, or more than one backend service, the overhead of adding a gateway is low and the long-term benefit is real. Retrofitting one later, after six services have their own auth implementations, is painful.

If your product has grown past a single frontend and a single backend, the gateway conversation is worth having with your team now rather than after the next incident.

At SpectreDev, this comes up in almost every architecture review — not because it's exciting infrastructure, but because the absence of it tends to explain a lot of pain.