message-queueslisted

# Message queues Queues distribute work (each message consumed once, then gone); streams record facts (each message read by many, retained). Most messaging pain comes from using one where the other fits. ## Method 1. **Pick the model from the consumption pattern.** One consumer pool doing jobs: queue (SQS, RabbitMQ). Multiple independent readers, replay, event history: stream/log (Kafka, Kinesis, Redpanda). "We might need replay later" is how queues get misused; be honest about whether messages are commands or events. 2. **Scope ordering to a key, or drop it.** Global ordering caps throughput at one consumer. Order per entity (partition key = order_id) covers real needs: same entity in sequence, entities in parallel. With plain queues, do not rely on FIFO-ish behavior; retries reorder. Consumers discard stale updates via sequence numbers. 3. **Design consumer groups around partitions.** In streams, one partition serves one consumer per group: more consumers than partitions idle; hot keys skew load. Pick partition counts with 2-3x headroom and keys with even cardinality; rebalancing pauses the group, so keep processing fast or use cooperative rebalancing. 4. **Ack after effect, expect redelivery.** Acknowledge (or commit offsets) only after the side effect is durable; the crash between effect and ack is why every consumer must dedupe or be idempotent (see idempotent-consumers). Auto-ack/auto-commit-on-receive silently converts