Message Queues and Event-Driven Architectures

In synchronous calls, system A must wait for system B to respond. If system B is down, the user request fails. Message queues (RabbitMQ, SQS) decouple this: system A pushes a message to the queue and returns success, while system B consumes the message asynchronously at its own pace.

In a Pub/Sub model, services publish events (e.g. "OrderPlaced") to a broker topic. Multiple subscriber services (e.g. EmailSender, InventoryManager, Billing) listen to that topic, receiving and processing copies of the event independently without coupling.

Event-driven systems trade immediate transactions for eventual consistency: databases reconcile eventually. To handle duplicate messages safely, consumers must be idempotent—processing the same message twice should yield the same result without duplicate charges.