2

I've been reading a lot on why one should use messages (w/ event sourcing/CQRS) for microservices communication and I get it. But most of the stuff I read online state that the main reason for using message brokers over direct http REST API communication is the cascade failure effect when a a service is down. Well, that can be solved by making services high available.

For me, the main reason behind using messaging is the fact that if one uses direct http requests then it's a synchronous request, even if using callbacks, the service is still expecting a response and that makes the microservices highly coupled, turning it into basically a distributed monolith (we kind of lose the microservices main benefits, right?).

With an event driven architecture the microservices are decoupled and it's certain that a given request will be executed eventually. But what if I need the requests do be executed synchronously? As far as I understand, a given user can make a request to create a certain entity, and if one the needed services is down, the user will just have to wait for it to go up again to see its entity created. The same goes with high loading scenarios, the "request" won't fail but it can take a long time to processed.

Not to mention read operations, those have to be synchronous.

So, I see two different use cases, using an event driven archicture in microservices is preferred because it enables low coupling between services, but it only fits eventual consistency scenarios. The other use case is when requests do have to be synchronous, would you still suggest using an event driven architecture? Or is it okay to use direct http REST calls between the services? Or microservices shouldnt be used at all when synchronous requests are a requirement?

Update: I changed some terms that were not correct and did not express what I meant

Improve this question
5
  • i can recommend the chris richardson microservices patterns book which covers a ton of ground around the areas you touch upon in your question.
    – simbo1905
    Commented Nov 11, 2020 at 19:09
  • "Well, that can be solved by making services high available."... Famous last words :)
    – c_maker
    Commented Nov 13, 2020 at 21:26
  • @c_maker I literally created an account here because I saw someone comment that in a similar question. I initally thought the same "why everyone assumes a service will fail and compromise the whole application? Uptime should be the biggest concern." But then I came to the conclusion that if someone decides to migrate from a monolith to microservices is because they probably want to escape its tightly coupled nature which difficults work division on big teams. Well,direct communication between services is a bit of a step back on that decision I'd say. Still better than monolith but not worth it
    – Leandro Costa
    Commented Nov 14, 2020 at 13:08
  • @LeandroCosta sorry did not mean to be too cheeky there. I just hear people say 'that', not really understanding what it means and assume things will always be available/working (think every millisecond of every second of every minute) and fail to build in reasonable fault tolerances, that is all.
    – c_maker
    Commented Nov 14, 2020 at 14:38
  • @c_maker oh, no problem! I just found it funny that someone mentioned it, I used to be one of those people who thought that was somewhat true :)
    – Leandro Costa
    Commented Nov 14, 2020 at 14:43

1 Answer 1

Reset to default
5

You mix a couple of things here, let's go in order:

1. "Event sourcing" is not a competing thing to "REST Endpoints", they have absolutely nothing to do with each other. "Event sourcing" is just a storage strategy for things that are best represented as a series of changes, instead of the end-state.

"REST API" (I think you just mean HTTP) is a communication technology. They are on completely different levels of architecture.

2. REST Endpoints are synchronous. No, they're not. Synchronicity is an implementation detail. You can call HTTP endpoints asynchronously very easily. Maybe you mean that the server has to do things immediately before returning the response. Even that isn't true, there is no such requirement of HTTP, nor REST.

3. Neither of the above makes services a "distributed monolith". A distributed monolith is the result of badly placed responsibilities, or often, no responsibilities at all. For example having a bunch of CRUD services and then one or few "smart" services that know almost everything. Or a bunch of small services that all know basically the same things (the same or similar events, data, formats, etc)

4. Event sourcing doesn't make services decoupled. See point above, decoupling is achieved by placing responsibilities correctly. Events sometimes help, but just having events that everybody has to know will still result in a big ball of mud.

With all that out of the way: Yes, you can use synchronous requests between services.

You should however prefer each service to be able to execute its "main function" without relying on other services. All the advantages are in this simple capability. This is what causes you service to be not just technically, but operationally independent from others.

Improve this answer
7
  • when i mention http is synchronous it's due to its request/response nature, where the caller waits until a response is available. Even if non blocking requests are made, it can have patches of code that are only executed after a response arrives, and those patches of code are tightly coupled to other services' availability. (+)
    – Leandro Costa
    Commented Nov 11, 2020 at 18:15
  • When i say distributed monolith in that case I'm refering to the fact that if a service fails, all the services that communicate directly with others would also fail. Monoliths are defined by its highly coupled nature, which is also present when microservices communicate directly with each other via http requests. I didn´t say event sourcing automatically makes it loosely coupled, I just said it enables it, as if, gives that possibility. But service decoupling cant be achieved with direct communication between services, right?
    – Leandro Costa
    Commented Nov 11, 2020 at 18:15
  • 1
    I don't really know what you mean. If you communicate with someone, you are obviously rely on the other side being available. If you communicate indirectly, like via a messaging server, Kafka, etc., you rely on those being available. You could argue that some technical aspects are "less coupled" in this case, but it has nothing to do with "event sourcing". I still can't concur with the statement that event sourcing "enables" loose coupling. Communication technology and event sourcing are two orthogonal concepts.
    – Robert Bräutigam
    Commented Nov 11, 2020 at 19:16
  • replace "event sourcing" with messaging, I misunderstood the term... with a messaging system you can achieve loose coupling easily because you don't communicate with services directly neither you wait for a resolved response. I don´t think we say we have tight coupling to a message broker, tight coupling is often refered, in this particular subject, as relying on another microservice to complete a given request, which is the case when microservices dont use message brokers and communicate directly. Correct me if I'm wrong. I dont want to sound rude because you helped me clearing some terms :)
    – Leandro Costa
    Commented Nov 11, 2020 at 20:24
  • No worries. If you mean messaging, then yes, that does have some "decoupling" effects. Like not knowing how many listeners there are, how they are organized, etc. In this sense, you might call direct communication tight coupling, I guess. But if those circumstances do not hold, i.e. there's clear communication paths, then direct communication is still better. Of course no communication, or even linking through the client is even better than both. But I see your point now.
    – Robert Bräutigam
    Commented Nov 11, 2020 at 21:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.