Styles of Microservice Communication

1. Communication through Common Data

💼 Implementation choices: File System, Persistent Data Store

📌 When to use:

Applications require high throughput without real-time delivery (GBs of data to a filesystem or million rows to a database)

✅ Pros:

⚠️ Limitations:

Developers have to build retry mechanism on their own
Tight coupling <- If data store changes structure in some way, communication might break

💼 Implementation choices: REST API

📌 When to use: Chain of calls (requests) have to be resolved in a strict order

✅ Pros:

⚠️ Limitations:

Temporal coupling: dependencies between services based on timing and availability - specifically when components must be simultaneously available and responsive for the system to function
High domain coupling: Senders have to know receivers' capabilities to make a request to appropriate server

💼 Implementation choices: gRPC, Queue-based brokers

📌 When to use: Chain of calls (requests) have to be resolved in a strict order in which has long-running processes

✅ Pros:

Avoid the concerns of Temporal Coupling, Client and Server can operate at their own rate

⚠️ Limitations:

More complex (than Request-Response with Synchronous Blocking)
There's a wide range of mix and match patterns, each type has trade-offs. People have to be smart to choose the right one.

💼 Implementation choices: Topic-based brokers

📌 When to use:

✅ Pros:

Low domain coupling: The event emitter is leaving it up to the recipients to decide what to do
Information hiding: changes in one module are less likely to affect other modules

⚠️ Limitations:

More complex in terms of infrastructure
Not friendly to developers' mental model
Need to mindful about the size of payload (perhaps not a bad thing if we think about information hiding)