event-driven

Event-driven systems use message queues like RabbitMQ, Kafka, or SQS to decouple services through asynchronous messaging. Set up a producer to publish events to a queue or topic, then configure consumers to subscribe and process those events reliably with built-in retry and acknowledgment semantics.

Pub/sub broadcasts events to multiple subscribers simultaneously, while message queues deliver each event to a single consumer. Pub/sub suits event notification patterns; queues excel at workload distribution and guaranteeing each message is processed exactly once across your distributed system.

Use the saga pattern to coordinate distributed transactions by breaking them into a sequence of local transactions orchestrated through events. Each service publishes events when its transaction completes or fails, allowing other services to react or trigger compensating actions for rollback.

Yes. Kafka stores an immutable log of events that serves as your event store, enabling event sourcing patterns where you rebuild application state by replaying events. This approach provides auditability, temporal queries, and natural integration with CQRS architectures.

Event-driven systems provide durable queues with dead-lettering for failed messages, configurable TTL, message acknowledgment to confirm processing, and idempotent processing patterns to handle retries safely without duplicating side effects.

RabbitMQ excels at reliable message routing and complex workflows with lower latency, while Kafka handles extreme throughput and long-term event retention. Choose RabbitMQ for transactional messaging and task queues; use Kafka for event streaming and analytics.