Day 7

Pub/Sub and Event-Driven Design

আজকে আমরা asynchronous architecture-এর design thinking শিখব। RabbitMQ শুধু code API না, এটি system boundary design করার টুল।

Pub/Sub মানে কী?

একটি event publish হলে multiple independent consumers সেটি পেতে পারে। উদাহরণ:

order created -> payment
order created -> analytics
order created -> email notification

Fanout Example


err := ch.ExchangeDeclare("orders.broadcast", "fanout", true, false, false, false, nil)
if err != nil {
	log.Fatal(err)
}
 
err = ch.Publish("orders.broadcast", "", false, false, amqp.Publishing{
	ContentType: "application/json",
	Body:        []byte(`{"order_id":77,"status":"created"}`),
})
if err != nil {
	log.Fatal(err)
}

Command vs Event

Type	Meaning	Example
Command	“এটি করো”	`send.invoice.email`
Event	“এটি হয়ে গেছে”	`invoice.generated`

Architecture Choice

Situation: User signup হলে profile service, email service, analytics service, audit log service react করবে।

Goal: Work queue না pub/sub?

What to think about:

সব consumer event পাবে
এক consumer-এর failure অন্যটাকে block করবে না
Future-এ নতুন subscriber যোগ হতে পারে

সম্ভাব্য সমাধান দেখুন

Pub/sub pattern best। Fanout বা topic exchange দিয়ে multiple independent queue bind করা যাবে। Work queue হলে event এক worker consume করেই শেষ হয়ে যাবে, যা ভুল behaviour।

Naming tip

Checkpoint

নিজে ভেবে দেখো: same payload payment আর analytics service ভিন্নভাবে consume করলে producer-এর কিছু বদলানো লাগা উচিত কি?

না, ideally না
consumer-specific logic producer-এ leak হওয়া উচিত না
এটাই loose coupling-এর value