1

I am trying to understand how event driven architecture is more efficient than traditional architecture. Of course it is loosely coupled.

Lets imagine this. We have 2 spring-boot microservices.

micro-service-A raises an event and micro-services-B listens to the event and does some action. With EDA approach, micro-service-B processes all those events sequentially one by one. In order to scale , I have to run multiple micro-service-B instances. But If I had used traditional approach, multiple HTTP requests would have been processed in parallel by a single server. So, with EDA approach, single threaded and sequential processing is not a good way of resource utilization right?

RamPrakash
  • 2,218
  • 3
  • 25
  • 54
  • Why do you say that the events are processed one by one? Even in a single-threaded microservice, most operations require a good amount of IO waiting, so they can be highly parallelized. – Francesc Castells Apr 26 '20 at 00:16
  • @FrancescCastells, Can I understand this way? This is expected. It is up to the consumer to process the requests in a non-blocking way. To increase the message/event processing speed, scale horizontally along with asynchronous / non-blocking. – RamPrakash Apr 26 '20 at 15:31
  • It is no different than in the API scenario. Both the api and the message processor can handle many concurrent operations thanks to multithreading. If also the operations are implemented as asynchronous, then you can increase a lot the concurrency because they don't block the threads. In any case, the operations are the same and they consume the same resources. The difference is that messaging is temporaly decoupled (the request and the execution don't need to happen at the same time) – Francesc Castells Apr 26 '20 at 15:47

1 Answers1

0

Event-driven doesn't imply linear event streams, event ordering or using Kafka for that matter.

Just as it has nothing to do with Event Sourcing, Domain-Driven Design or sagas. All you need to do is publish an event to some messaging infrastructure, so downstream systems can consume it.

Event-driven is essentially messaging. It's not new and all messaging patterns are properly described in the "Patterns of Enterprise Application Architecture" book by Martin Fowler. There is nothing in messaging that says a single word about sequential single-threaded processing.

Just as you load-balance HTTP calls, you use competing consumers with a message broker to scale horizontally. All popular message brokers support competing consumers, it's a well-known pattern that the industry uses for decades.

Alexey Zimarev
  • 17,944
  • 2
  • 55
  • 83
  • `competing consumer` is nothing but a horizontal scaling of microservice-B in my example. The book might not say about single / multi threading. Mostly message processing would be sequential. What you are saying is - it is up to the consumer to process the messages using multiple threads once it is received. – RamPrakash May 16 '20 at 18:01
  • You compared the "traditional approach" with HTTP load balancing, which, by definition, cannot do ordered processing. _Nothing_ changes with EDA compared to that. Competing consumers and load balancers act the same way. Concerning the ordering, Google has a very good article https://cloud.google.com/pubsub/docs/ordering#do_i_really_have_order – Alexey Zimarev May 16 '20 at 19:38