Event-Driven Architecture

Decoupling with Queues

Synchronous HTTP calls between microservices create tightly coupled systems that fail cascadingly. If Service A calls Service B synchronously, and Service B is down, Service A fails too. Event-driven architecture solves this by introducing a Message Broker (like RabbitMQ or Apache Kafka) in the middle.

RabbitMQ vs Kafka

• RabbitMQ: A "smart broker, dumb consumer" model. Best for traditional task queueing where messages are ephemeral. It pushes messages to consumers and deletes them once acknowledged.
• Kafka: A "dumb broker, smart consumer" model. Best for high-throughput event streaming. It persists messages to disk as an immutable append-only log. Consumers track their own offsets and can "replay" events from the past.

Handling Failures: Dead-Letter Queues (DLQ)

If a consumer receives a message but crashes during processing (e.g., due to a malformed payload or a database timeout), it shouldn't just drop the message or retry infinitely. Instead, after N failed retries, the message should be routed to a Dead-Letter Queue. Engineers can monitor the DLQ, fix the underlying bug, and then replay the messages back into the main queue.