What is the goal of customer service via “shipping status routes”?

The shipping service. Customer service calls the API gateway for this.

The catalogue service gets a new internal address. Which clients need to be adapted?

None. Browser and customer service address the API gateway; only its catalog route points to the new destination.

Should browsers call up the catalogue service directly instead of via the gateway? How do you weigh up?

It saves an intermediate step. For this, clients know internal goals, and access rules would have to be repeated per service. The gateway bundles both, but is an additional building block at the edge.

Pattern familyChapter II · Communication · Building block 8 of 9

Gateway, Mesh & Discovery

An API gateway bundles external access to multiple internal destinations. It takes over routing and common access rules at the system edge.

By Michael Meierhoff · Meierhoff Systems

Shared accessClients only know the gateway.
RoutingEach route to the destination.
System edgeAccess rules bundled at the edge.

Context

Why this is important

Without shared access, clients know each internal destination individually, and changes to internal services hit them directly. Internal service communication and contract content are separate building blocks.

This building block explains the API gateway at the external access. Service Discovery and Mesh concern internal service communications; for business interface content see API contracts.

At a glance · An entrance for many services

Web and mobile only talk to the API gateway, which forwards requests to the appropriate service.

Shop example · Building blocks and relationships

External access for three internal goals

Variant: Catalogue and shipping were separated as services for proven operational reasons. Browser and customer service access shop routes exclusively via the API gateway.

This is how you read the picture

Shared access The arrows browser and customer service to the API gateway, both via HTTPS.
Routing The arrows “Checkout routes”, “Catalog routes” and “Shipment status routes” from the API gateway.
System edge The box API gateway in the area of platform, in front of the boxes in the area of internal services.

Clients address the gateway; it forwards each route to the responsible internal destination.

Benefits & limitations

Helps if:

A shared entry point consolidates cross-cutting policies for external access.
A mesh mediates internal connections and supports their protection and observation.
Dynamically emerging service instances remain findable via Discovery.

Boundaries

Business rules in a gateway make it a change bottleneck; keep its role focused on cross-cutting functions such as routing and access.
Gateway, Service Mesh and Discovery have different trust boundaries; assign policies explicitly to each connection.
A central entry point shall not replace a test per zone; see Trust Boundaries.

In practice

Assign Gateway, Mesh and Discovery separate responsibilities. Keep business decision out of generic forwarding and check where identity is enforced.
Set time budget, authentication, and error response for each connection. Observe which layer rejects or redirects a request.
Test Discovery as instances change and when the mesh fails. Trust Boundaries defines trust zones; Observability connects signals.

Read the detailed explanation

Gateway, Service Mesh and Discovery have distinct roles. A gateway consolidates external entry and policies. A mesh mediates internal service connections. Discovery locates currently reachable service instances.

Clear boundaries keep routing, security rules and business decisions distinct. Configuration, identity, time budgets and failures must remain traceable across their respective connections.

Trust Boundaries identifies where identity and input are checked again; Observability connects rejected and forwarded requests across runtime components.

A gateway handles north-south traffic entering from outside; a service mesh handles east-west traffic between services. A modular monolith usually needs neither.

Check your understanding

Test yourself in three stages

ReadingCheck in the picture
What is the goal of customer service via “shipping status routes”?
View the solution with justification
The shipping service. Customer service calls the API gateway for this.
ApplyingTransferred to a new situation
The catalogue service gets a new internal address. Which clients need to be adapted?
View the solution with justification
None. Browser and customer service address the API gateway; only its catalog route points to the new destination.
EvaluateWeighing an alternative
Should browsers call up the catalogue service directly instead of via the gateway? How do you weigh up?
View the solution with justification
It saves an intermediate step. For this, clients know internal goals, and access rules would have to be repeated per service. The gateway bundles both, but is an additional building block at the edge.

Explore further

These optional deepenings complement the learning goal of this page.

Backend for Frontend

A Backend for Frontend (BFF) is a client-specific intermediary that assembles data from the responsible services for a web or mobile interface. It can combine requests and omit unnecessary details. Business rules and data ownership remain with those services; the additional intermediary needs its own owner and observability.

For testingCompare BFF at the shop. For the mobile order view, put together a compact status of order, payment and shipping. Check what additional details the web view needs and what business rules remain with the relevant services.

References

Continue on the learning path

Next in Communication & APIs: API versioning.

9 Building blocks

Continue withAPI versioning