Template description
The client sends Request /metrics to API Gateway and does not address anyone else. The gateway calls Service A with Auth and rate limit, and Service A returns Auth result on a dashed arrow. Only after that return does the gateway send Business query to Service B. Service B returns Response payload, again dashed, to the gateway. The gateway then sends Aggregated reply back to the client. Service A and Service B never exchange a message. The business query is gated by the auth result. The client sees one reply, not the two downstream payloads.
When to use it
Read it when a caller wants to invoke Service B directly, or when Service B is being asked to enforce the rate limit. The sequence puts both the auth check and the aggregation on the gateway, which is the boundary you need in an API review.
How to adapt it
Replace /metrics with the route you are actually explaining, and rename Service A and Service B. If rate limit lives on a third hop, insert that participant between the gateway and Service A. If the reply is not aggregated, rename Aggregated reply to the body you return. Add a rejection arrow from the auth result if a denied call should never reach Service B. In this drawing that rejection is not shown.