Message Queues & Event-Driven Architecture

Synchronous request-response communication works well for simple interactions, but it creates tight coupling and struggles with variable load. Message queues and event-driven architecture decouple producers from consumers, enabling resilient, scalable systems.

---

Why Message Queues?

Synchronous (tightly coupled):

┌──────────┐    HTTP     ┌──────────┐    HTTP     ┌──────────┐
│ Service A│────────────▶│ Service B│────────────▶│ Service C│
└──────────┘             └──────────┘             └──────────┘
  If B is slow, A waits. If C is down, B fails. Everything is coupled.

Asynchronous (decoupled via queue):

┌──────────┐  publish   ┌───────────┐  consume   ┌──────────┐
│ Service A│───────────▶│  Message  │───────────▶│ Service B│
└──────────┘            │   Queue   │            └──────────┘
                        └───────────┘
  A does not wait for B. B processes at its own pace.
  If B is down, messages wait in the queue.

Benefits

Benefit	Description
Decoupling	Producer and consumer operate independently
Buffering	Queue absorbs traffic spikes
Reliability	Messages persist until processed
Scalability	Add more consumers to increase throughput
Fault tolerance	Consumer failures do not affect the producer

---

Pub/Sub vs Point-to-Point

Point-to-Point (Queue)

One message is consumed by exactly one consumer.