Is microservice architecture using message queues and event driven architecture same

Question

Edit v1: I have been going through some system design videos and learnt about microservice architecture using message queues and event-driven architecture.

But I don't seem to find any substantial point of difference between the two. Both have different components/services publishing or subscribing to eventBus/messagingQueues and performing the tasks associated with the published event.

Is microservice architecture with messaging queues a subset of event driven architecture or is there something more to it that I need to figure out.

---

Original V0: I have been going through some system design videos and learnt about microservice architecture and event-driven architecture.

But I don't seem to find any substantial point of difference between the two. Both have different components/services publishing or subscribing to eventBus/messagingQueues and performing the tasks associated with the published event.

Is microservice architecture a subset of event driven architecture or is there something more to it that I need to figure out.

Answer 1

Event Driven Architecture is a system design concept where we use "techniques" to achieve synchronous or asynchronous communication in our system. More likely than not we want asynchronous communication.

Such techniques can be pub/sub, long polling, Queueing, websockets and etc.

Microservice is an approach to designing our system where we make our services decoupled to one another or at least we try our best to. For example, Facebook's newsfeed service is independent of other services like Profile, photos and messaging. One benefit of this is "separation of concerns", so for example if newsfeed goes down we can still continue to upload photos and chat our friends. If FB was "monolith", one service going down could have taken down the whole site. Another benefit of microservice is deployability, the smaller the service the faster to test and deploy.

Let's take pizza for example, deciding whether to cut it in squares or triangular, or how big/small the slices are is thinking microservices. Which one to eat first and next is thinking event-driven. Do you go for the larger slices, mixed, small ones or meatier ones? Just like how our systems can decide intelligently what events to trigger next.

Just remember that these are concepts to help you understand an existing system, or help you decide how you would build your system. In the real-world when you onboard to a new company you'll find yourself asking questions like

• How service-oriented is the system?
• How eventful is the flow of data?

---

Short answer to your question... they're not necessarily related but inevitably we implement them together when scaling one or the other.

For example given this microservice architecture

 [checkout service] ---> [email service]

Let's say the user waits very long for checkout and email to finish. 90% of the wait is coming from the email service. In reality the user should be able to continue browsing the other pages while they wait for the email.

In this example we solved the long wait time by adding Queue

 [checkout service] ---> [Queue] ---> [email service]

We've improved user experience by making our microservice more eventful. When the user clicks the checkout button, a response is returned immediately allowing the user to continue browsing while the "email event" is dispatched to the queue.

Answer 2

Short answer: No, these are not the same and not subsets.

Both have different components/services publishing or subscribing to eventBus/messagingQueues and performing the tasks associated with the published event.

This is wrong. Microservices are not necessary about events and publishing/subscribing.

Answer 3

In this case Wikipedia tackles this very question.

From a formal perspective, what is produced, published, propagated, detected or consumed is a (typically asynchronous) message called the event notification, and not the event itself, which is the state change that triggered the message emission. Events do not travel, they just occur. However, the term event is often used metonymically to denote the notification message itself, which may lead to some confusion. This is due to Event-Driven architectures often being designed atop message-driven architectures, where such communication pattern requires one of the inputs to be text-only, the message, to differentiate how each communication should be handled.

https://en.wikipedia.org/wiki/Event-driven_architecture

I'll be honest, I treated them the same when designing and writing code. But I guess technically there is a difference, as per the paragraph quoted above.

Answer 4

Technically we cannot use the word "Same" in this case. Below will give a clear relation between these artifacts:

Event-driven Microservices rely on message queues (to store/forward messages) to send/receive events, wrapped in messages.

Answer 5

Event-driven architectures usually leverage messaging technology in order to transport the information that something has happened in the past from one place to another or many other places.

Message queues can also be used in a non-event driven architecture, for instance, to perform asynchronous request/response communication.

In addition, when using an event-driven approach the information that is transmitted is usually different, it is just indicating what (business) event has happened with usually fewer information than provided by normal messages.

For instance, you can send a message to create a new order in an online shop system and the message could contain all the information the receiver needs to process it. The important thing is also that there is dedicated receiver of the message.

In the event-driven approach some component would rather send some order checkout requested event (or similar) without knowing what other component or what other components (think of publish/subscribe mechanisms) will "listen* to that event and perform corresponding actions. In such an architecture it would also make sense to send other events before the actual checkout happens, such as new shopping cart created or item added to cart event.

So the event-driven approach also implies some kind of choreography between your Microservices where more complex business operations can include lots of events published and processed by different components without having one central component which orchestrates who gets what information in what order.

Of course, from my experience, it makes perfect sense to combine event-driven choreography and non-event driven orchestration in a Microservices architecture depending on the use cases.