Once we have decomposed the application into autonomous services, an inevitable question arises: how do they communicate with each other and how does the outside world find them? Communication is the nervous system of a distributed architecture, and choosing the wrong style (synchronous versus asynchronous) or infrastructure (gateway, service discovery) can turn a set of elegant services into a fragile distributed monolith.

In this lesson we will compare synchronous communication (REST, gRPC) with asynchronous communication (messaging, events), understand the role of the API Gateway as an entry point, and see how service discovery allows services to locate each other in a dynamic environment.

1. Synchronous versus asynchronous
2. Synchronous communication: REST and gRPC
3. Asynchronous communication: messaging and events
4. API Gateway
5. Service Discovery
6. Choosing the right style
7. Common mistakes and tips
8. Exercises
9. Conclusion

The first major decision is whether the caller waits for the response (synchronous) or continues without waiting (asynchronous).

The key idea of temporal coupling: in a synchronous call, the target service must be available at that instant. In an asynchronous one, the message waits in a queue until the destination can process it.

REST over HTTP is the de facto standard: simple, universal, based on resources and HTTP verbs.

The timeout is essential: without it, a slow service would block the caller indefinitely (remember the fallacy "latency is zero").

gRPC uses HTTP/2 and binary serialization (Protocol Buffers), which makes it faster and more compact, ideal for high-performance internal communication.

From this contract, gRPC automatically generates the client and server code. A quick comparison:

In asynchronous communication, a service publishes a message on a broker (RabbitMQ, Apache Kafka, etc.) and others consume it when they can. We distinguish:

• Commands: a request for something to happen ("SendReceipt"). They usually have a single recipient.
• Events: a notification of something that already happened ("PolicyCreated"). They can have many subscribers.

This event describes a fait accompli. The billing service can subscribe to generate the first receipt, and the notifications service can subscribe to send a welcome email, without the policies service knowing anything about them. This drastically reduces coupling.

Idempotency is critical because brokers usually guarantee "at least once" delivery, which means a message may arrive duplicated.

The API Gateway is the single entry point for external clients. Instead of the frontend knowing the address of each microservice, it talks only to the gateway, which routes and aggregates.

Typical responsibilities of the gateway:

Each route associates a URL pattern (predicates) with a target service (uri). The lb:// prefix indicates that the specific address is resolved through service discovery, not hardcoded by hand.

Beware: the gateway must not contain business logic. If you turn it into a central brain, you are back to the monolith.

In the cloud, service instances appear and disappear continuously (autoscaling, deployments, failures). Their IP addresses are not fixed. Service discovery solves the problem: a central registry where services register themselves and look each other up by name.

There are two models:

In Kubernetes, discovery is built in: each service has a stable DNS name and the cluster balances automatically.

With this definition, any pod can call http://policies-service:8080 and Kubernetes routes to a healthy instance, without anyone managing IPs.

A practical guide for deciding:

• Do you need the response now to continue (validate a data item, show a screen)? → Synchronous.
• Are you notifying something that already happened, to several interested parties? → Asynchronous (events).
• Do you want the target service to be able to be down without affecting you? → Asynchronous.
• Is the operation a simple, low-latency query? → Synchronous (internal gRPC or REST).

The general principle: prefer asynchronous to reduce coupling, and reserve synchronous for queries that really need an immediate response.

• Chained synchronous calls: A calls B, which calls C, which calls D. Latency and the probability of failure accumulate. Consider events.
• Forgetting timeouts: every synchronous call must have a timeout. Without it, a slow service drags you down.
• Putting business logic in the gateway: the gateway routes and protects, it doesn't decide. The logic lives in the services.
• Assuming exactly-once delivery: brokers deliver "at least once". Make consumers idempotent.
• Hardcoding IPs by hand: use service discovery; addresses change constantly.

1. Compare synchronous and asynchronous communication in a table in terms of temporal coupling, availability, and consistency.
2. Explain why an event consumer must be idempotent and show in Java pseudocode how to achieve it.
3. You have a screen that needs to show, in a single call, the customer's data and their policies, which live in different services. Which piece of the architecture would you use and how?

1. Synchronous: high temporal coupling (both must be alive), availability dependent on the destination, immediate consistency. Asynchronous: low temporal coupling (the message waits in a queue), independent availability, eventual consistency.

2. It must be idempotent because brokers deliver "at least once", so a message may arrive duplicated. Solution:

3. The API Gateway with an aggregation pattern (or a BFF, Backend For Frontend): the gateway receives the request, calls the customers service and the policies service in parallel, and combines both responses into a single JSON that it returns to the screen. This way the frontend makes a single call.

We have learned that communication between services moves between two poles: synchronous (REST, gRPC), simple but coupled in time, and asynchronous (events, messages), decoupled but eventually consistent. The API Gateway provides a single entry point that routes, protects, and aggregates, while service discovery allows services to find each other in a dynamic environment.

All this network communication shares one risk: dependencies fail. The next lesson, Resilience Patterns: Circuit Breaker, Retry, and Bulkhead, will teach us to design services that survive partial failures instead of propagating them.