2.2. Asynchronous Messaging Fundamentals

Asynchronous messaging decouples producers from consumers in time: the sender does not wait, and the broker absorbs bursts and outages that would otherwise cascade. The price is a new class of problems — delivery guarantees, ordering, duplicate handling, and messages that can never be processed. This chapter contrasts queue and log architectures (RabbitMQ, Kafka, Pulsar), pins down the precise meaning of at-least-once versus exactly-once, and treats schema evolution and dead-letter handling as the production-critical concerns they are.

Topics Covered

• 2.2.1. Message Queue vs. Event Streaming: Differences and Use Cases: Distinguishes transient message queues from replayable event logs and the use cases each one fits.
• 2.2.2. Kafka Architecture: Topic, Partition, Consumer Group, Offset: Dissects Kafka’s topic, partition, consumer-group, and offset model, and the ISR replication that backs durability.
• 2.2.3. Pulsar vs. Kafka: Architectural Comparison: Compares Pulsar’s broker/storage separation against Kafka’s coupled design and what each means operationally.
• 2.2.4. RabbitMQ: Exchange Types and Routing: Covers RabbitMQ’s exchange types and routing model for flexible message delivery topologies.
• 2.2.5. At-Least-Once, At-Most-Once, and Exactly-Once Semantics: Pins down the precise meaning of at-most-once, at-least-once, and exactly-once, starting from the Two Generals problem.
• 2.2.6. AsyncAPI: Documenting Asynchronous Contracts: Introduces AsyncAPI as the contract standard for documenting event-driven and message-based interfaces.
• 2.2.7. Schema Evolution and Schema Registry: Avro, Protobuf, and Compatibility Modes: Explains backward, forward, and full compatibility modes and the deploy ordering each one imposes.
• 2.2.8. Dead Letter Queues and Poison Message Handling: Covers the anatomy of a poison-message loop, dead-letter queues, redrive workflows, and the ordering caveat.