Event-Driven Architecture (EDA)
Event-ই center — system "react" করে state change-এ।
একটি traditional system: User registration হলে — code-এ explicit call: sendWelcomeEmail(),
createProfile(), addToAnalytics()। নতুন কাজ যোগ = registration code change। EDA-তে:
registration শেষে শুধু UserRegistered event emit; অন্য system listen করে react করে। Tight
coupling-এর বিপরীত।
EDA কী?
Event-Driven Architecture = একটি architectural pattern যেখানে state change-কে event হিসেবে publish করা হয়, এবং interested service-গুলো সেই event-এ react করে। Communication-এর primary mechanism = events।
Event vs Message vs Command
Event
- Past tense (UserRegistered, OrderPlaced)
- Something happened
- Many listeners
- Sender knows nothing about receiver
- "Notification" character
Command
- Imperative (RegisterUser, PlaceOrder)
- "Do this"
- One handler typically
- Sender expects action
- Direct intent
Message
- Generic term
- Event বা command — both
- Transport unit
- Header + payload
- Wider concept
EDA-র মূল components
- Event Producer: Event publish করে।
- Event Consumer: Event subscribe করে react করে।
- Event Channel/Broker: Event transport (Kafka, RabbitMQ)।
- Event Schema: Event-এর structure (Avro, JSON Schema)।
- Event Store: Persistent log (Event Sourcing-এ)।
উদাহরণ — E-commerce
Traditional approach:
EDA approach:
EDA Patterns
১. Event Notification
Event লাইট — শুধু ID/reference। Consumer চাইলে details fetch।
২. Event-Carried State Transfer
Event-এ পুরো state। Consumer এই data store করে — source-এ যেতে হয় না।
৩. Event Sourcing
সব state event-এ। Replay দিয়ে current state derive। (পরের chapter)।
৪. CQRS (Command Query Responsibility Segregation)
Read ও write আলাদা — write event-driven, read denormalized।
সুবিধা
- Loose coupling: Producer ও consumer independent।
- Scalability: Async + parallel processing।
- Flexibility: নতুন consumer = নতুন feature, no producer change।
- Real-time: Event-এ সাথে সাথে react।
- Audit trail: Events log সব history।
- Resilience: Failure isolated।
Challenges
Eventual Consistency
সব service-এ instant sync না। User update করেই এক service-এ পুরাতন data দেখতে পারেন।
Event Schema Evolution
Event format বদলালে — old consumer ভাঙে। Backward compatible essential।
Debugging
Event-এর chain trace কঠিন। Correlation ID + distributed tracing দরকার।
Message Ordering
Cross-partition order maintain কঠিন।
Duplicate Handling
At-least-once delivery → idempotent consumer।
Complex Workflow
Multi-step business flow track করা — saga pattern, workflow engine (Temporal)।
কখন EDA?
- Multiple service একই event-এ react করবে।
- Real-time requirement।
- Loose coupling চাই।
- Audit trail / event sourcing।
- High throughput async processing।
- Microservice architecture।
- Future feature flexibility।
কখন EDA না?
- Simple CRUD app।
- Strong consistency mandatory।
- Simple sequential workflow।
- Small team — operational overhead।
Implementation Tools
- Apache Kafka: Most popular event streaming।
- AWS EventBridge: Managed event bus।
- Google Pub/Sub: Managed cloud।
- NATS: Lightweight, fast।
- RabbitMQ: Traditional broker।
- Apache Pulsar: Cloud-native streaming।
বাস্তব উদাহরণ
- Uber: Trip events flow through Kafka।
- Netflix: Viewing event → recommendation, billing, analytics।
- LinkedIn: Activity feed event-driven।
- Airbnb: Booking lifecycle event-driven।
- Banking: Transaction → fraud detection, audit, reporting।
Best Practices
- Event = past tense (OrderPlaced, not PlaceOrder)।
- Schema versioning (Avro, Protobuf)।
- Idempotent consumer।
- Correlation ID — request trace।
- Dead Letter Queue।
- Event-এ enough context — chatty fetch এড়াতে।
- Don't over-event — simple call OK।
সাধারণ ভুল ধারণা
- "EDA = microservices": Microservice ছাড়াও EDA সম্ভব। Modular monolith-এ ও।
- "Event = command": ভিন্ন — event past, command future।
- "EDA always better": Simple app-এ overkill।
📌 চ্যাপ্টার সারমর্ম
- EDA = state change → event → consumer react।
- Event past tense; command imperative।
- Loose coupling, scalability, flexibility — main benefits।
- Eventual consistency, debugging — main challenges।
- Kafka, EventBridge, Pulsar — top tools।