---
title: "Comment by Synfinity Dynamics Pvt Ltd on \"Event-Driven Architecture: A Practical Guide for Beginners\" | Hashnode"
description: "Great explanation of why Event-Driven Architecture exists instead of jumping straight into Kafka or RabbitMQ. I especially liked the point that architectural pr"
url: "https://hashnode.com/posts/event-driven-architecture-a-practical-guide-for-beginners/6a3b7c5fc7d3d43210db3dce/comment/6a3e07f04ba9a0bc5e7cef37"
---

[Discussion](https://hashnode.com/posts/event-driven-architecture-a-practical-guide-for-beginners/6a3b7c5fc7d3d43210db3dce)

Comment [Event-Driven Architecture: A Practical Guide for Beginners](https://hashnode.com/posts/event-driven-architecture-a-practical-guide-for-beginners/6a3b7c5fc7d3d43210db3dce)

[Synfinity Dynamics Pvt Ltd](https://hashnode.com/@synfinity-dynamics)

[Jun 26](https://hashnode.com/posts/event-driven-architecture-a-practical-guide-for-beginners/6a3b7c5fc7d3d43210db3dce/comment/6a3e07f04ba9a0bc5e7cef37)

Great explanation of why Event-Driven Architecture exists instead of jumping straight into Kafka or RabbitMQ. I especially liked the point that architectural problems should drive technology choices, not the other way around.

One thing I'd add is that as teams adopt EDA, designing events themselves becomes just as important as choosing the broker. Clear event naming, versioning, idempotent consumers, and observability can make the difference between a scalable system and one that's difficult to debug.

Curious to hear your thoughts do you usually recommend starting with a simple message queue like SQS/RabbitMQ and moving to Kafka only when throughput or streaming requirements justify it?

[Awais Ahmad](https://hashnode.com/@itsahmadawais)

[Jun 26](https://hashnode.com/posts/event-driven-architecture-a-practical-guide-for-beginners/6a3b7c5fc7d3d43210db3dce/comment/6a3e07f04ba9a0bc5e7cef37#reply-6a3e60d70bb7459b7742eb56)

Appreciate it! I agree that event design is often more important than the broker itself.

I'd usually start with the simplest solution that meets the requirements. For many teams, that's SQS because it's serverless and operationally simple.

As the system grows and requirements around routing, replayability, or event streaming emerge, that's when I'd evaluate RabbitMQ or Kafka.

The problem should always drive the technology.