An API Gateway centralizes client access to microservices through a single entry point, whereas direct client-to-microservice communication has clients calling each service's endpoint directly.
Key Points: • With an API Gateway, clients only need to know one address, and the gateway routes each request to the correct backend service. • Direct communication requires every client to know the location and contract of every service it depends on, which becomes unmanageable as services grow. • An API Gateway centralizes cross-cutting concerns like authentication, rate limiting, and TLS termination, instead of duplicating that logic in every service. • Direct communication avoids the extra network hop and potential bottleneck the gateway introduces, but pushes complexity and security decisions out to every client. • An API Gateway can also aggregate multiple backend calls into a single client-facing response, which isn't possible with pure direct communication.
Example: A mobile app hitting an API Gateway makes one call to /api/order-summary, and the gateway internally fans that out to the Order, Payment, and Shipping services and combines the results, instead of the app having to call all three services itself and merge the responses on the client.
Interview Tip: A concise interview answer is:
"An API Gateway gives clients one entry point that handles routing, security, and aggregation, so clients don't need to know about every backend service. Direct client-to-service communication skips that extra hop but pushes discovery, security, and aggregation logic onto every client, which doesn't scale well as the number of services grows."