Communication Patterns and Asynchronous Integration in Microservice Architectures

In a monolithic single‑process application, components call each other directly via language‑level methods or function calls, creating strong coupling when objects are instantiated directly (e.g., new ClassName()) and looser coupling when using dependency injection. All objects run in the same process.

When transitioning to a microservice‑based architecture, the biggest challenge is changing the communication mechanism. Directly converting in‑process calls to RPC calls can lead to poor performance and inefficient communication in a distributed environment. This is known as the "distributed computing fallacy," which lists common mistaken assumptions developers make when moving from a single‑design to a distributed design.

There is no single solution; instead, isolate business microservices as much as possible and replace fine‑grained in‑process communication with coarse‑grained, asynchronous communication between internal services. Group calls and return aggregated results to the client.

Microservice‑based applications run as distributed systems across multiple processes, services, servers, or hosts. Each service instance typically runs in its own process and must interact via inter‑process communication protocols such as HTTP, AMQP, or binary protocols like TCP, depending on the service’s nature.

The community promotes the "smart endpoints and dumb pipes" principle, encouraging highly cohesive services with their own data and domain logic, orchestrated via REST calls rather than complex protocols or centralized workflow engines.

Common communication protocols include synchronous HTTP request/response and asynchronous lightweight messaging. The following sections detail these topics.

Communication Types

Clients and services can communicate using various styles, categorized along two axes.

First axis – synchronous vs. asynchronous protocols:

Synchronous protocols (e.g., HTTP) where the client sends a request and waits for a response. The client code may be synchronous (blocked) or asynchronous (non‑blocked) but the protocol itself is synchronous.

Asynchronous protocols (e.g., AMQP, RabbitMQ) where the sender does not wait for a response; messages are placed on a queue for later processing.

Second axis – single receiver vs. multiple receivers:

Single‑receiver communication, such as command patterns, where each request is handled by one service.

Multiple‑receiver communication, which must be asynchronous (e.g., publish/subscribe in event‑driven architectures) and can be implemented with topics and subscriptions on a message bus.

Microservice applications often combine these styles; the most common pattern is synchronous HTTP/HTTPS for single‑receiver calls and asynchronous messaging for inter‑service communication.

Asynchronous Microservice Integration Enhances Autonomy

When building microservice‑based applications, minimize internal service communication. If integration is required, it should be asynchronous, not relying on synchronous request/response chains that create tight coupling and reduce resilience.

Avoid synchronous dependencies between services, especially for queries. Synchronous chains increase overall response time and make the system fragile when any service in the chain degrades.

Instead, use eventual consistency by propagating needed data via integration events or asynchronous messages, allowing each service to operate autonomously even if others are down.

Data duplication across services is acceptable when it helps each service maintain its own bounded context, as illustrated by the eShopOnContainers example where a user entity is duplicated as a "Buyer" entity in the ordering service.

Any protocol can be used for asynchronous communication—event buses, message brokers, or even HTTP polling—provided it does not create synchronous dependencies.

Communication Styles

Depending on the chosen communication type, various protocols and options are available. Synchronous request/response mechanisms typically use HTTP and REST, especially when exposing services outside a Docker host or microservice cluster. Internal communication may use binary protocols like TCP or WCF, while asynchronous messaging can use AMQP.

Message formats may be JSON, XML, or binary; non‑standard binary formats are discouraged for public APIs.

HTTP and REST Request/Response Communication

In request/response communication, the client sends a request and the service processes it and returns a response. This model suits real‑time UI data queries and is commonly used for most read operations in microservice architectures.

Clients expect responses within seconds; for longer latency, asynchronous messaging should be employed.

REST, built on HTTP, is the most popular architectural style for creating services, with verbs like GET, POST, and PUT. Tools can generate client stubs from rich metadata (e.g., OpenAPI/Swagger).

Additional Resources

Martin Fowler – Richardson Maturity Model: https://martinfowler.com/articles/richardsonMaturityModel.html

Swagger – Official site: https://swagger.io/

For real‑time one‑to‑many communication, frameworks like ASP.NET SignalR and protocols such as WebSockets enable server‑push scenarios, illustrated below.

SignalR efficiently pushes updates to many clients, useful for scenarios like live sports score updates.

---

For further discussion, join the Knowledge Planet "Chief Architect Circle" or contact the provided WeChat, QQ groups, and other community channels.