API Gateway Pattern - System Design Explained for Beginners

Imagine a shopping app on a phone. When a visitor opens the catalogue, the app asks a server for product information. When they open their order history, it asks for their orders. An API is the agreed way for one program to ask another for information or an action.

An API gateway is a front door for several APIs. It receives a request, applies shared rules and routes it to the appropriate application. The application still decides whether the requested action is allowed and performs the work.

A request has a method that describes the action, a path that identifies what it concerns, and sometimes a body containing data. GET /products asks to read products. POST /orders asks to create an order. A response contains a status and, often, data.

GET /products

200 OK
{"products": [{"id": "tea", "price": 10}]}

The client and server need a clear agreement about fields, units and errors. Is price in rupees, dollars or the smallest currency unit? What happens when a product is missing? A gateway can enforce some rules, but it cannot invent a correct agreement between the app and the service.

Authentication asks who the caller is. Authorization asks whether that caller may do this action. Knowing someone’s identity does not allow them to read another person’s orders. Services should enforce ownership and business permissions, even if the gateway also checks access.

Choose a request in the lab, then send it through the teaching gateway. Products are public in this example; order history requires a recognised identity and permission. An unknown path has no destination.

The demo accepts at most three successful requests in one manual window. The next otherwise-valid request receives 429 until you start a new window. This deliberately simple rule is not a real gateway implementation or a product quota. The identity and permission switches are teaching inputs, not security controls.

Rate limiting restricts how quickly a caller can send work. It helps control overload, but limits should match real application capacity. A slow service may also need a timeout: a deadline after which the gateway stops waiting and returns an error. A timeout does not prove that a write failed; the service might have completed it before its response was lost.

If the app retries a payment or order, blindly repeating the request can duplicate the action. An idempotency key identifies one intended action so the application can recognise a retry and return the previous result rather than creating another order. Persist that decision with the relevant write; a gateway alone cannot guarantee it.

A gateway also needs a failure plan. Run enough capacity across appropriate failure boundaries, monitor errors and response time, and keep sensitive request data out of logs. Adding a single gateway in front of several healthy services can otherwise create one new point of failure.

Representative options checked 6 October 2026. A free software licence does not remove hosting or maintenance costs. Product editions, plugins, deployment modes and billing differ; verify the features you actually need.

• NGINX Open Source can serve as a reverse proxy and HTTP traffic router. It may be sufficient for a small existing web application; a proxy configuration is not automatically a complete API management platform.
• Envoy is open-source proxy software used in service infrastructure. Its flexibility brings configuration and operational work; check documentation for your stable deployed version.
• Kong Gateway provides routing and extensible plugins, with open-source and commercial deployment choices. Check which edition includes each authentication, management and support feature.
• Amazon API Gateway is a managed service. Pricing depends on API type and usage. HTTP APIs and REST APIs do not have identical features; compare their capabilities before choosing.

Benchmark requests per second at your target response time using the actual identity checks, plugins, payloads and backend behaviour. AWS throttling targets describe service controls, not your application’s sustained capacity. There is no universal throughput ranking for these products.

One small website on servers you already operate

Start by asking whether an existing NGINX proxy and application-level checks meet the need. A separate gateway platform adds configuration and recovery work. Add it when central policies or multiple service teams justify that work.

Several service teams need consistent API policies

Evaluate Kong or an Envoy-based deployment when teams need shared routing and policy control on their own infrastructure. Compare plugin coverage, operating skills and commercial support. Keep business decisions such as order ownership inside the services.

AWS APIs with limited time for host maintenance

Evaluate Amazon API Gateway and choose the API type that supports the required integrations and controls. Managed operation reduces host upkeep, while ongoing charges, limits and AWS-specific configuration affect the decision.

For every choice, test an unavailable backend, a lost response after a write, and a gateway failure. A successful demonstration request is only one part of a dependable design.

Use Gateway Aggregation for combined responses and Backends for Frontends for meaningful client-specific needs. Chain of Responsibility explains ordered checks without assuming a local pipeline resolves remote failures.

An API defines how programs communicate. A gateway can centralise routing and shared checks, while services still own business permissions and reliable writes. Choose a gateway from the hosting environment, team skills and required controls.

Rate limits, timeouts and retries need explicit behaviour. Measure the complete request path and plan how both the gateway and its backends recover.