Need some insight on Lagom's architecture

Lagom
1

Hi All,

Are there documented lagom specific patterns for solely using the message broker for all comms? The reason I ask is that in a lot of the microservice literature that I’ve read, it seems that async comms is the way forward i.e. all events on a message broker…so I’m a little confused as to why there is a prominent client/service API pattern in use for lagom, forgive my ignorance…but could someone provide some justification for that please?

Thanks in advance! =)

1 Like
2

Hi @cchanning,

Here’s how I always explain the need for async communication as well as sync communication in distributed systems.

There’re 2 possibilities when services talk together:

  • One service ask something to another service.
  • One service tell something to another service.

The “ask pattern” correspond to the sync communication protocol.
Your service need to get an information that is handled by another service. It just asks to this service. If the service is down, it could be considered as a negative answer.

The “tell pattern” correspond to the async communication protocol.
Your service need to tell something to an other service and this information should not be lost.
The sync communication is not usable here because if the service that receive the information is down, the information will be lost.
You can mitigate the problem with some retries but how many retry will you do ? What if the service never goes up again ?
So here, sync communication is not a viable solution.
We need to pass through an async communication protocol: a highly available message passing system (Kafka by default in Lagom, for example).

Now, you should understand when you should use sync or async communication between your services.

The last thing you need to understand is distributed transactions.
Distributed transactions are the nightmares of distributed systems developers.
You should know them in order to avoid them !
I’ll not explain you here what are distributed transactions but here is a good blog article about them and about how to work around them: http://www.grahamlea.com/2016/08/distributed-transactions-microservices-icebergs/

I hope I answered to some of your questions.

Cheers,
Jules

2 Likes
3

When Lagom was first written, request/reply via HTTP was generally how things were done across the industry. The publish/subscribe via Kafka and friends became popular thereafter. So hopefully, that’s the why that you seek.

My view is that you need both patterns with a strong bias toward pub/sub events. I see this as the definition of being an “event first” microservice.

1 Like
4

Thanks for the responses all, @huntc yes I had suspected as much.