At-Least-Once Delivery

TL;DR

Explanation

Three delivery guarantees: at-most-once (may lose), at-least-once (may duplicate), exactly-once (ideal, expensive). At-least-once: broker retries unacknowledged messages. Consumer crashes after processing but before ack → redeliver → process twice. Handling duplicates (idempotency): deduplication table (message ID + status), natural idempotency (UPDATE SET status = 'sent' WHERE status = 'pending'), INSERT IGNORE. Kafka: at-least-once by default (manual offset commit after processing). RabbitMQ: at-least-once with manual ack. SQS: at-least-once by design. Message IDs: always include unique ID to detect duplicates.

Common Misconception

Why It Matters

Common Mistakes

• Non-idempotent consumer with at-least-once broker — double charges, double emails.
• Not including message ID for deduplication.
• Using exactly-once where at-least-once + idempotency suffices — unnecessary complexity.

Code Examples

// Non-idempotent consumer — charges customer twice on redeliver:
function handlePayment($msg) {
    charge($msg['amount']); // No idempotency check
    ack($msg);
}

// Idempotent with deduplication:
function handlePayment($msg) {
    $processed = DB::table('processed_payments')
        ->where('message_id', $msg['id'])->exists();
    if ($processed) return ack($msg); // Already done — skip

    DB::transaction(function() use ($msg) {
        charge($msg['amount']);
        DB::table('processed_payments')->insert(['message_id' => $msg['id']]);
    });
    ack($msg);
}

References

• ↗ https://www.cloudcomputingpatterns.org/at_least_once_delivery/

Tags

Related Terms