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.