Which tool should you choose for an API Gateway?

Question

IT Interview Practice · Accepted Answer

**Choose an API gateway by the rules it must enforce and the team's ability to operate it.** The number of microservices alone does not determine the product.

Suppose a shop has order and customer services. Its first need may simply be to expose one address and forward each request to the correct service. Later, external partners may require separate credentials, usage limits and audit records. Those are different requirements and can lead to different choices.

## 1. Decide what belongs at the gateway

A gateway is the entry point that forwards requests and applies shared policies. For example, it can check that a caller has a valid token before sending an order request onward.

```text
Client -> Gateway -> /orders -> Order service
                  -> /users  -> User service
```

The order service still checks whether that caller may access the particular order. Central authentication does not replace authorization over business data. Keep business workflows in services; if a client needs several responses combined, a separate backend for that client may be clearer than adding that logic to every gateway route.

## 2. Turn requirements into a short list

Write down required protocols, authentication, per-customer limits, logging, deployment constraints and expected traffic. Then compare candidates against those same requirements.

| Situation | Candidate to evaluate | Why it fits | Cost to consider |
|---|---|---|---|
| A few routes and a team already running NGINX | NGINX as a reverse proxy | Straightforward request forwarding may cover the actual need | Extra API policies require appropriate modules or other components |
| Many APIs need consistent configurable policies | Kong Gateway | Plugins provide a way to apply reusable policies | The team must manage configuration, availability and plugin compatibility |
| AWS workloads and a preference for managed operations | Amazon API Gateway | AWS operates the gateway service | Feature differences, service limits, usage costs and provider dependence |

NGINX documents its [proxy behavior](https://nginx.org/en/docs/http/ngx_http_proxy_module.html). Check the exact product edition and extensions before treating a requested policy as included.

For AWS, HTTP APIs and REST APIs have different capabilities. For example, the documented choice for API keys and per-client usage management is REST APIs. Compare the [feature matrix](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-vs-rest.html) before selecting by price or product name.

## 3. Check the operational consequences

Every request now depends on this entry point. Ask who will update policies, diagnose failures and restore a bad configuration. A feature-rich product can still be a poor fit if the team cannot operate it reliably.

- Define timeouts so a slow backend does not hold resources indefinitely. Coordinate them with the caller's overall deadline.
- Retry only when the operation is safe to repeat. A payment timeout does not prove that the payment failed; an idempotency key can help the payment service recognize repeated attempts.
- For a limit shared across gateway instances, check how counters are coordinated and what happens if their shared store fails. Independent local counters do not automatically create one global limit.
- Version configuration, review changes and rehearse rollback. Replicas provide little help if all receive the same broken routing rule.

These checks often narrow the choice more effectively than a long feature list because they expose the work the team will own after launch.

## 4. Prove the choice with a small realistic test

Send representative traffic through a candidate. Test invalid credentials, a slow service, an unavailable gateway instance and a configuration rollback. Measure additional latency, errors and resource usage, and confirm that customer limits behave correctly across instances.

For the shop with a few routes and existing NGINX expertise, I would first test whether its current proxy setup meets the requirements. For many shared API policies, I would evaluate Kong; for an AWS team prioritizing managed operations, I would evaluate Amazon API Gateway. **Choose the simplest option that passes the required behavior and failure tests**, then document the conditions that would justify changing it.

Situation	Candidate to evaluate	Why it fits	Cost to consider
A few routes and a team already running NGINX	NGINX as a reverse proxy	Straightforward request forwarding may cover the actual need	Extra API policies require appropriate modules or other components
Many APIs need consistent configurable policies	Kong Gateway	Plugins provide a way to apply reusable policies	The team must manage configuration, availability and plugin compatibility
AWS workloads and a preference for managed operations	Amazon API Gateway	AWS operates the gateway service	Feature differences, service limits, usage costs and provider dependence

1. Decide what belongs at the gateway

2. Turn requirements into a short list

3. Check the operational consequences

4. Prove the choice with a small realistic test

関連する質問