Is API Gateway Justified?

This article is an analysis of the decision taken to use an api gateway and to see if that decision is justified.

Here are the scientific method steps for making such decisions:

1. Understand the decision.

2. Produce some options.

3. Evaluate the options.

4. Decide on one option.

5. Communicate your decision.

Understand

The digital banking system supports iOS, Android, a web portal, and a support SAAS (Zendesk) clients, each with its own needs. Here is the system context diagram.

The question wasn’t whether we needed a robust API layer, but how to organize it. Do we let each client call backend services directly, or put one or more API gateways in front?

The Options

We sketched two main approaches:

• Direct Client-to-Service Calls: Each client (mobile app, web app, Zendesk) talks directly to every backend service it needs.

• API Gateways (BFF-style): We give each client its own API gateway (for example: Mobile API Gateway, Portal API Gateway, Zendesk API Gateway).

Evaluating the options

With direct client-to-service calls, each client app would need to keep track of endpoints.

Pros: Simplicity to start, no extra infrastructure. 

Cons: Each client handles its own routing, and versioning. Clients may flood us with many small calls, and every service must expose a public endpoint.

With gateways, clients interact with a single, well-designed API instead of dealing with multiple services directly.

Pros: Each gateway tailors APIs to its client’s needs (payload shaping, auth rules, versioning), while still providing the shared benefits of an API gateway (security, rate limits, logging). This simplifies client development.

Cons: More infrastructure to run (multiple gateway instances).

The Decision

We liked the BFF idea that gives each front-end its own gateway. That way each gateway can shape and limit data exactly for its client.

The API Gateway pattern won on flexibility and control. They act as a single “front door” or reverse proxy to all our services.

By routing all client requests through gateways, we can implement cross-cutting functions once (authentication, SSL, IP whitelisting, caching, logging etc.) instead of sprinkling that logic into every service. This doesn’t mean backend services wont run authorization and logging code.

API Gateways can even transform protocols on-the-fly. For example, accepting REST calls and calling a gRPC backend under the hood.

Mobile traffic can be formatted and versioned separately from portal traffic.  Zendesk webhooks can be translated into our internal formats without exposing services publicly. 

This clean separation avoids leaking “mobile-only” data or logic into the web portal, and vice versa.  It also isolates failures: if we redeploy the Mobile Gateway, the Portal Gateway continues serving web users uninterrupted.

Communicating the decision

This diagram shows the decision taken. The system has dedicated API gateways for mobile, web, and support (Zendesk) clients.

 Each gateway offers useful out-of-the-box features.  We get rate limiting, and DDoS protection by default. For instance, one config change can throttle a runaway client rather than letting it slam the database.

Logging and metrics become centralized at the gateway; developers can see all incoming request patterns and latency there, easing monitoring.

We also hook the gateways into our Auth/IAM system, so every call is pre-authorized (JWT checks, API keys, etc.) at the edge.

In effect, an API Gateway is our traffic cop to the backend.

Capturing the Decision in an ADR

To justify our choice, we’ve drafted this Architecture Decision Record (ADR).

Here are the guidelines to write an ADR properly:

• Metadata: The ADR has a title (e.g. “Use of API Gateways”), a Date, Deciders’ names, and a Status (Proposed, Approved, etc.). We include author and approver for accountability . This lives in source control so history and decisions are traceable.

• Context: We describe the scenario. Multiple frontend channels (mobile app, web portal, Zendesk), and we list the alternatives: centralized API management vs direct calls. We don’t state the decision yet.

• Decision: In clear, affirmative language, we state our choice: “We will use API Gateways…”, not “We think we should use gateways…”. No hesitation. We lead with confidence, then follow with the why behind the decision.

• Consequences (Trade-offs): We enumerate the downsides: need for HA clustering, added latency. This way, future readers immediately see the costs of the decision.

By writing the ADR, we build a record that any team member can understand why API gateways are in place.

Summary

Using API Gateways was the clear winner. They give us centralized control and frontend-specific flexibility.

We acknowledge the minor latency hit and extra upkeep, but we considered that a worthy trade for cleaner setup.

Just remember to record the decision: write that ADR now, not later. Future you (or your team) will thank you for the clarity.

Related Materials

• See how a justified architect tailor the architecture diagrams for each target audience. Business, Devops, Leads, and Developers, each have distinct concerns. Communicate Like an Architect: Digital Bank Architecture Diagrams

• Get exclusive deep dives, private notes, behind-the-scenes thinking, and raw experience from the field. Exclusive insights from the mind of a pragmatic architect.