This document discusses communication patterns in microservices architectures. It compares synchronous vs asynchronous communication and how they impact coupling between services. It defines different types of coupling, such as implementation, temporal, deployment, and domain coupling, and provides recommendations for how to reduce or manage each type of coupling. Remote communication patterns like circuit breakers, retries, and sagas are presented for surviving communication failures between loosely coupled services.

1. Loosely or Lousily Coupled?
Understanding
Communication Patterns in
Microservices Architectures
@berndruecker

2. Let‘s talk about food

3. How does ordering Pizza work?
Pizza
Place
You
Phone Call
Synchronous blocking communication
Feedback loop (ack, confirmation or rejection)
Temporal coupling (e.g. busy, not answering)
Pizza
Place
You
Email
Asynchronous non-blocking communication
No temporal coupling
Pizza
Place
You
A feedback loop might make sense
(ack, confirmation or rejection)
Email
Confirmation Email

4. Feedback loop != result
Pizza
Place
You
Email
Confirmation Email
Pizza Delivery
Feedback (ACK, confirmation, rejection)
Result

5. Synchronous blocking behavior for the result?
Bad user experience
Does not scale well

6. Scalable Coffee Making
https://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html
Photo by John Ingle
@berndruecker

7. Scalable Pizza making
La Pizza Cresci Cannes
https://www.maison-cresci.com/
from http://www.travellingsnail.com/content/la-pizza-cresci-cannes

8. PUT/order
Synchronous results?
Pizza
Place
You
Pizza Delivery
HTTP 200
The task of
Pizza making is
long running

9. Only the first communication step is synchronous
Pizza
Place
You
PUT/order
HTTP 200
Pizza Delivery
The task of
Pizza making is
long running

10. bernd.ruecker@camunda.com
@berndruecker
http://berndruecker.io/
Bernd Ruecker
Co-founder and
Chief Technologist of
Camunda

11. Making Pizza is long running

12. A workflow engine provides long running capabilities
Workflow Engine
Scheduler
Durable State
Workflow Definitions
V1
V2
Workflow Engine:
Is stateful
Can wait
Can retry
Can escalate
Can compensate
Provides visibility

13. Execute Processes
One process instance gets started.
It is persisted in the workflow
engine and „walks“ through the
process model.
@PUT
retrievePayment() {
result = workflowEngine.
startProcessInstance('payment')
if (result.hasEnded())
return 'paymentSucceeded'
else
return 'paymentSucceeded'
}
Your code to provide
a RESTendpoint
Instance
Id
Process
Definition
Current
State
…
…-7454 payment „Charge
Credit
Card“
…
…-4571 payment „Charge
Credit
Card“
…
Process Instance Table
Durable state of
workflow engine
(e.g. via relational database)
Your glue code to
implement the RESTcall
@Task('chargeCreditCard')
chargeCreditCard() {
...
restClient.put(
'http://creditCards/charge/',
requestData)
}
Credit Card
Service
REST

14. Value Proposition of a Workflow Engine
Value of Visibility
Value of
long running
capabilities
Process
Orchestration
Business Transactions,
Sagas
Solving challenges
with remote communication
Integration Patterns
Graphical Programming
Effort of introducing
a workflow engine

15. This is orchestration – right?

16. Command vs. event-based communication
Pizza
Place
You
I order this pizza
OK – got it
Command = Intent
Cannot be ignored
Independant of communication channel
Pizza
Place
You
„Hey – I am hungry!“
Event = Fact
Sender can't control what happens

17. Events vs. Commands
„Pizza Salmon
is ready!“
I baked this pizza for Andrea.
Please package it immediately and
deliver it while it‘s hot!

18. Definitions
Event = Something happened in the past. It is a fact.
Sender does not know who picks up the event.
Command = Sender wants s.th. to happen. It has an intent.
Recipient does not know who issued the command.

19. Choreography
Hey – somebody
ordered
Hey – Pizza is
ready

20. Orchestrator
Command

21. Definition
Orchestration = command-driven communication
Choreography = event-driven communication

22. Let‘s switch examples: Order fulfillment
Checkout
Payment
Inventory
Shipment
Order
placed
Payment
received
Goods
shipped
Goods
fetched
@berndruecker

23. Event chains
Checkout
Payment
Inventory
Shipment
Order
placed
Payment
received
Goods
shipped
Goods
fetched
@berndruecker

24. Phil Calcado at QCon NYC 2019

25. Order
Fulfillment
Orchestration and Choreography
Checkout
Payment
Inventory
Shipment
Payment
received
Order
placed
Retrieve
payment
@berndruecker
This is
choreography
This is
orchestration

26. Order
Fulfillment
Collaboration style is independant of communication style
Checkout
Payment
Inventory
Shipment
Payment
received
Order
placed
Retrieve
payment
@berndruecker
Choreography
Orchestration
Asynchronous
non-blocking
Asynchronous
non-blocking
Synchronous
blocking

27. Some code?
https://github.com/berndruecker/flowing-retail/tree/master/kafka
@berndruecker

28. Sam Newman: Building Microservices
@berndruecker

29. Mix orchestration and choreography
Orchestration
Orchestration
Orchestration
Choreography
@berndruecker

30. Want to learn more about choreography vs. orchestration?
https://learning.oreilly.com/library/view/practical-process-automation/9781492061441/
30 days trial: https://learning.oreilly.com/get-learning/?code=PPAER20
Recording from QCon: https://drive.google.com/file/d/1IRWoQCX-gTPs7RVP5VrXaF1JozYWVbJv/view?usp=sharing
Slides: https://www.slideshare.net/BerndRuecker/gotopia-2020-balancing-choreography-and-orchestration

31. Communication Options – Quick Summary
Communication
Style
Synchronous
Blocking
Asynchronous
Non-Blocking
Collaboration
Style
Command-Driven Event-Driven
Example REST
Messaging
(Queues)
Messaging
(Topics)
Feedback Loop
HTTP
Response
Response
Message
-
Pizza Ordering via Phone Call E-Mail Twitter
This is not the
same!

32. Coupling

33. Types of Coupling
Type of coupling Description Example Recommendation
Implementation Coupling Service knows internals of
other services
Joined database Avoid

34. Types of Coupling
Type of coupling Description Example Recommendation
Implementation Coupling Service knows internals of
other services
Joined database Avoid

35. Types of Coupling
Type of coupling Description Example Recommendation
Implementation Coupling Service knows internals of
other services
Joined database Avoid
Temporal Coupling Service depends on
availability of other
services
Synchronous blocking
communication
Reduce or manage

36. Types of Coupling
Type of coupling Description Example Recommendation
Implementation Coupling Service knows internals of
other services
Joined database Avoid
Temporal Coupling Service depends on
availability of other
services
Synchronous blocking
communication
Reduce or manage

37. Types of Coupling
Type of coupling Description Example Recommendation
Implementation Coupling Service knows internals of
other services
Joined database Avoid
Temporal Coupling Service depends on
availability of other
services
Synchronous blocking
communication
Reduce or manage
Deployment Coupling Multiple services can only
be deployed together
Release train Typically avoid, but
depends

38. Types of Coupling
Type of coupling Description Example Recommendation
Implementation Coupling Service knows internals of
other services
Joined database Avoid
Temporal Coupling Service depends on
availability of other
services
Synchronous blocking
communication
Reduce or manage
Deployment Coupling Multiple services can only
be deployed together
Release train Typically avoid, but
depends

39. Types of Coupling
Type of coupling Description Example Recommendation
Implementation Coupling Service knows internals of
other services
Joined database Avoid
Temporal Coupling Service depends on
availability of other
services
Synchronous blocking
communication
Reduce or manage
Deployment Coupling Multiple services can only
be deployed together
Release train Typically avoid, but
depends
Domain Coupling Business capabilities
require multiple services
Order fulfillment requires
payment, inventory and
shipping
Unavoidable unless you
change business
requirements or service
boundaries

40. Types of Coupling
Type of coupling Description Example Recommendation
Implementation Coupling Service knows internals of
other services
Joined database Avoid
Temporal Coupling Service depends on
availability of other
services
Synchronous blocking
communication
Reduce or manage
Deployment Coupling Multiple services can only
be deployed together
Release train Typically avoid, but
depends
Domain Coupling Business capabilities
require multiple services
Order fulfillment requires
payment, inventory and
shipping
Unavoidable unless you
change business
requirements or service
boundaries
This is influenced with the communication
or collaboration style

41. Remote Communication

42. Messaging?

43. Patterns To Survive Remote Communication
Service
Consumer
Pattern/Concept Use With
Service
Provider
X Service Discovery Sync (X)
X Circuit Breaker Sync
X Bulkhead Sync
(X) Load Balancing Sync X
X Retry Sync / Async
X Idempotency Sync / Async X
De-duplication Async X
(X) Back Pressure & Rate Limiting Sync / (Async) X
X Await feedback Async
X Sagas Sync / Async (X) …

44. Circuit
Breaker
Photo by CITYEDV, available under Creative Commons CC0 1.0 license.

45. Circuit Breaker
Webshop
You
PUT/order Address
Check
Payment
from https://martinfowler.com/bliki/CircuitBreaker.html

46. Circuit Breaker
Webshop
You
PUT/order Address
Check
Payment
@CircuitBreaker(name = BACKEND, fallbackMethod =
"fallback")
public boolean addressValid(Address a) {
return httpEndpoint.GET(...);
}
private boolean fallback(Address a) {
return true;
}
e.g. Resilience4J:
resilience4j.circuitbreaker:
instances:
BACKEND:
registerHealthIndicator: true
slidingWindowSize: 100
permittedNumberOfCallsInHalfOpenState: 3
minimumNumberOfCalls: 20
waitDurationInOpenState: 50s
failureRateThreshold: 50

47. https://www.infoworld.com/article/3254777/application-development/
3-common-pitfalls-of-microservices-integrationand-how-to-avoid-them.html

48. Stateful retry
Webshop
You
PUT/order Address
Check
Payment
Workflow
Engine
Scheduler
Durable State

49. Loosely or Lousily Coupled?
Type of coupling Description Example Recommendation
Implementation Coupling Service knows internals of
other services
Joined database Avoid
Temporal Coupling Service depends on
availability of other
services
Synchronous blocking
communication
Reduce or manage
Deployment Coupling Multiple services can only
be deployed together
Release train Typically avoid, but
depends
Domain Coupling Business capabilities
require multiple services
Order fulfillment requires
payment, inventory and
shipping
Unavoidable unless you
change business
requirements or service
boundaries

50. Summary so far…
• Know
• communication styles (sync/async)
• collaboration styles (command/event)
• You can get rid of temporal coupling with asynchronous communication
• Make sure you or your team can handle it
• You will need long running capabilities (you might need it anyway)
• Synchronous communication + correct patterns might also be OK
• Domain coupling does not go away!

51. Want to learn more…
https://ProcessAutomationBook.com/
Free electronic version available
Featuring code examples:

52. Thank you!
@berndruecker

53. mail@berndruecker.io
@berndruecker
https://berndruecker.io
https://medium.com/berndruecker
https://github.com/berndruecker
Contact:
Slides:
Blog:
Code:
https://ProcessAutomationBook.com/