Which instance?
Distributes traffic among multiple instances of the same service to improve scalability and availability.
Lesson 4 · Service routing
One API address. Multiple backend services.
The client always calls localhost:7412. The API Gateway reads the HTTP path and decides whether User, Catalog, Inventory, Cart, Order, or Payment Service should handle the request.
Interactive architecture lab
Change the path, not the destination.
Select different APIs and watch the same gateway route each request to exactly one responsible service.
Choose an APIDestination stays the same
Gateway URL
http://localhost:7412/api/users
You can run the same request in Postman.
Start the lesson, then execute a request through the API Gateway.
Execute a request to inspect the original response.
Execute a request to inspect the response headers.
One public address
L7
Client-facing address
inspect path
localhost:7412Routing decision
/api/users → User ServicePublished address
localhost:7412The only API address known by the client.Container listener
apiGateway1:80Nginx accepts requests here inside Docker.Routing input
HTTP request pathThe path selects a service type, not a replica.Implementation
Nginx location rulesEach location forwards to one private upstream.location /api/users { proxy_pass http://user_service; }
location /api/products { proxy_pass http://catalog_service; }
location /api/orders { proxy_pass http://order_service; }
API Gateway log · path → service / server
Start the lesson to see routing decisions.
Private upstreams
E-commerce services
Observe the routing decision
Which service handled the selected API?
The gateway selects a service from the request path. It is not choosing among replicas of the same service.
Latest route
WAITING
Execute a request to reveal the path decision.
Client destinationlocalhost:7412
Selected path/api/users
Selected serviceUser Service
- 1Start the lessonThe trace will show how a path becomes a service decision.
What this teaches
Use one entry point for many services.
An API Gateway sits in front of backend services and acts as a single entry point for client requests. It examines the request and routes it to the correct service.
Client→API Gateway→Appropriate Service
Without an API Gateway, the client may need to know the address of every service. With a gateway, the client knows one endpoint while paths such as /api/users, /api/products, and /api/orders select the appropriate backend.
Common gateway responsibilities
- Authentication and authorization
- Rate limiting
- Request routing
- Request and response transformation
- Logging and monitoring
- API versioning
Different decisions
API Gateway vs Load Balancer
They are often used together, not as replacements for each other.
Which service?
Routes requests among different services and APIs, with API-level policies around that routing.
Client→API Gateway→Load Balancer→Service Instance
What this gives us
- One stable API address for clients
- Clients are decoupled from service locations
- Internal service addresses remain hidden
- Central routing and cross-cutting policies
- Services can evolve behind the gateway
What still remains
- The single API Gateway is now a Single Point of Failure (SPOF)
- Each service has only one instance in this lesson
- A gateway route does not distribute load among service replicas
- Gateway capacity and availability must eventually scale too