4 ms·

Usually better to use asynchronous communication between services.

discreteevent 8y ago
With a good old fashioned message broker for guaranteed eventual delivery, decoupling, discovery and elasticity (if you can fit it in to your setup)
- sigmonsays 8y ago
  I can't tell if this is a joke or not.
  - discreteevent 8y ago
    I'm not joking. Just to be clear, I'm taking asynchronous to mean a call that is not transactional. Where you are ok with eventual consistency. If something is transactional then keep it in one service. Make it an action not a transaction and save yourself a lot of grief. So if something is asynchronous then why not back it up with a message broker and get the properties I listed (in earnest).
    - SuddsMcDuff 8y ago
      I'd be interested to know if anyone's had success with distributed transactions in a microservice architecture. I've gotten into a world of pain every time I've tried. We did have some success at one of my previous companies (wiggle.co.uk), but that was mainly due to pretty tight integration between MSMQ, MSDTC and MS Sql Server. Even then, we tried to avoid distributed transactions as much as possible.
bni 8y ago
On its own this is a worthless hand wavy statement. How do you accomplish this when you have a synchronous client (ie a user waiting in his web browser)? Should the browser poll for the result? How could you possibly implement something like this in the real world?
- discreteevent 8y ago
  If it is synchronous or transactional then don't use microservices. Plenty of things can be done asynchronously provided the use case is ok with eventual consistency or within a non urgent time limit. BTW now that the browser supports websockets (a bidirectional protocol the rest of the world had since the 70s!), you don't have to poll.
- SuddsMcDuff 8y ago
  Your comment seems to be a slightly clumsy way of saying "I don't know much about this area of software design, please tell me more", so I'll respond to it in that spirit. Firstly my terse hand wavey statement was at least clear on the fact that it was talking about communication between services. It said nothing about web browsers or any other human interface. But since this relatively narrow context is clearly the one which you can most relate to, I'll stay within it. If you think about it, the HTTP request/response cycle is actually an illusion of synchronous communication on top of a transport mechanism which is fundamentally asynchronous. It's an abstraction layer which shields you from the complexities of asynchronous communication. Broadly speaking this is known as the [request/response](https://en.wikipedia.org/wiki/Request%E2%80%93response https://en.wikipedia.org/wiki/Request%E2%80%93response) pattern. HTTP by no means the only implementation of the request/response pattern. Even in asychronous messaging systems it's not unusual to see it implemented - https://www.enterpriseintegrationpatterns.com/patterns/messaging/RequestReply.html https://www.enterpriseintegrationpatterns.com/patterns/messa.... But request/reply is just one of the patterns which exists in the realm of asynchronous communication. There are other, much more common patterns such as send/receive and publish/subscribe. Exploring these patterns opens up whole new approaches to software design. I wholeheartedly recommend the book [Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/ https://www.enterpriseintegrationpatterns.com/) by Gregor Hohpe and Bobby Woolf. It's quite old now but is still the best and most complete introduction to asynchronous design. An alternative perspective is from the viewpoint of [Command Query Separation](https://en.wikipedia.org/wiki/Command%E2%80%93query_separation https://en.wikipedia.org/wiki/Command%E2%80%93query_separati...), and it's relative at the architural level, [Command Query Responsibility Segregation](https://martinfowler.com/bliki/CQRS.html https://martinfowler.com/bliki/CQRS.html).
sagichmal 8y ago
It is almost never better to use async communication between services. The failure modes are strictly more, and finding and fixing problems is substantially harder. https://programmingisterrible.com/post/162346490883/how-do-you-cut-a-monolith-in-half https://programmingisterrible.com/post/162346490883/how-do-y...
- SuddsMcDuff 8y ago
  Are you basing that on personal experience, or just on that blog post?
  - sagichmal 8y ago
    The blog post elegantly reflects my own experiences.
    - SuddsMcDuff 8y ago
      I found the blog post to be awful, the rationalization of a man stuck in a particular mindset who failed to adapt to a new paradigm. The line "You have publish-subscribe, but you really want request-response." says it all. He simply cannot imagine a software design which doesn't depend on synchronous request/response.
- discreteevent 8y ago
  Part of that article seems to be saying: I don't see any point in having suspension in vehicles. When I overload my truck it handles like shit.

With a good old fashioned message broker for guaranteed eventual delivery, decoupling, discovery and elasticity (if you can fit it in to your setup)

sigmonsays 8y ago
I can't tell if this is a joke or not.
- discreteevent 8y ago
  I'm not joking. Just to be clear, I'm taking asynchronous to mean a call that is not transactional. Where you are ok with eventual consistency. If something is transactional then keep it in one service. Make it an action not a transaction and save yourself a lot of grief. So if something is asynchronous then why not back it up with a message broker and get the properties I listed (in earnest).
  - SuddsMcDuff 8y ago
    I'd be interested to know if anyone's had success with distributed transactions in a microservice architecture. I've gotten into a world of pain every time I've tried. We did have some success at one of my previous companies (wiggle.co.uk), but that was mainly due to pretty tight integration between MSMQ, MSDTC and MS Sql Server. Even then, we tried to avoid distributed transactions as much as possible.

bni 8y ago

On its own this is a worthless hand wavy statement. How do you accomplish this when you have a synchronous client (ie a user waiting in his web browser)? Should the browser poll for the result? How could you possibly implement something like this in the real world?

discreteevent 8y ago
If it is synchronous or transactional then don't use microservices. Plenty of things can be done asynchronously provided the use case is ok with eventual consistency or within a non urgent time limit. BTW now that the browser supports websockets (a bidirectional protocol the rest of the world had since the 70s!), you don't have to poll.
SuddsMcDuff 8y ago
Your comment seems to be a slightly clumsy way of saying "I don't know much about this area of software design, please tell me more", so I'll respond to it in that spirit. Firstly my terse hand wavey statement was at least clear on the fact that it was talking about communication between services. It said nothing about web browsers or any other human interface. But since this relatively narrow context is clearly the one which you can most relate to, I'll stay within it. If you think about it, the HTTP request/response cycle is actually an illusion of synchronous communication on top of a transport mechanism which is fundamentally asynchronous. It's an abstraction layer which shields you from the complexities of asynchronous communication. Broadly speaking this is known as the [request/response](https://en.wikipedia.org/wiki/Request%E2%80%93response https://en.wikipedia.org/wiki/Request%E2%80%93response) pattern. HTTP by no means the only implementation of the request/response pattern. Even in asychronous messaging systems it's not unusual to see it implemented - https://www.enterpriseintegrationpatterns.com/patterns/messaging/RequestReply.html https://www.enterpriseintegrationpatterns.com/patterns/messa.... But request/reply is just one of the patterns which exists in the realm of asynchronous communication. There are other, much more common patterns such as send/receive and publish/subscribe. Exploring these patterns opens up whole new approaches to software design. I wholeheartedly recommend the book [Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/ https://www.enterpriseintegrationpatterns.com/) by Gregor Hohpe and Bobby Woolf. It's quite old now but is still the best and most complete introduction to asynchronous design. An alternative perspective is from the viewpoint of [Command Query Separation](https://en.wikipedia.org/wiki/Command%E2%80%93query_separation https://en.wikipedia.org/wiki/Command%E2%80%93query_separati...), and it's relative at the architural level, [Command Query Responsibility Segregation](https://martinfowler.com/bliki/CQRS.html https://martinfowler.com/bliki/CQRS.html).

sagichmal 8y ago

It is almost never better to use async communication between services. The failure modes are strictly more, and finding and fixing problems is substantially harder. https://programmingisterrible.com/post/162346490883/how-do-you-cut-a-monolith-in-half https://programmingisterrible.com/post/162346490883/how-do-y...

SuddsMcDuff 8y ago
Are you basing that on personal experience, or just on that blog post?
- sagichmal 8y ago
  The blog post elegantly reflects my own experiences.
  - SuddsMcDuff 8y ago
    I found the blog post to be awful, the rationalization of a man stuck in a particular mindset who failed to adapt to a new paradigm. The line "You have publish-subscribe, but you really want request-response." says it all. He simply cannot imagine a software design which doesn't depend on synchronous request/response.
discreteevent 8y ago
Part of that article seems to be saying: I don't see any point in having suspension in vehicles. When I overload my truck it handles like shit.