Choosing Messaging and Delivery Semantics

AMQP/JMS brokers treat receiving as destructive: an acknowledgment deletes the message, so a consumer added today cannot reread yesterday's messages
Log-based brokers append to an on-disk log; consuming is read-only, and the consumer offset can be rewound to reprocess messages with new code
A disk-based log acts as a large bounded buffer — typically days of messages — so a slow consumer can usually catch up before it starts missing data

A log totally orders messages only inside one partition: put all events of one entity in the same partition by using the entity ID as the partition key
Load balancing shares a topic among consumers one message at a time, but redelivery after a crash inevitably reorders messages; a separate queue per consumer avoids this
Shard-per-consumer parallelism is capped by the partition count, and one slow message blocks its shard; expensive messages favor per-message load balancing instead

Restarting from the last recorded offset reprocesses messages after it: the effect can be made effectively-once with idempotent writes that store the triggering message offset alongside each value
Microbatching (Spark Streaming) and checkpointing (Flink) discard partial output like a batch job, but only inside the framework — external side effects happen again on retry
Dataflow, VoltDB, and Kafka Streams keep state changes and messaging inside one atomic commit; idempotence additionally assumes deterministic processing, in-order replay, and fencing of failed nodes

Choosing Messaging and Delivery Semantics — A Decision Tree