Idempotensi dan Deduplikasi Pesan

Distributed systems deliver messages at least once. A timeout or retry can make the same request arrive twice — and charge a card or create an order twice.

An operation is idempotent if doing it many times has the same effect as doing it once. Repeating it changes nothing beyond the first application.

Some operations are idempotent by nature — absolute SET, HTTP PUT and DELETE. Others, like balance = balance + 10, double-apply on a retry.

The standard fix is an idempotency key: the client generates a unique id per operation and resends it on every retry, so the server processes it only once.

The server records each processed key. If the same key reappears, it returns the stored result instead of re-running the work.

For queues, the consumer does deduplication: it tracks message ids it has already handled and silently skips any repeats.

Recording the key and doing the work must be atomic. If they are separate, a crash between them reopens the duplicate window — use a transaction or unique constraint.

You cannot store keys forever. Give the dedup store a TTL sized to your max retry window — Redis with expiry is a common choice.

True exactly-once delivery is extremely hard. The practical pattern is at-least-once delivery plus idempotent processing, giving effectively-once behavior.

Make event handlers idempotent: include a unique event id, prefer absolute state changes, and guard side effects so a redelivered event never repeats them.

Apply idempotency at every retry boundary — API gateways, queue consumers, saga steps, webhooks. Anywhere a message can arrive twice needs a dedup strategy.

The same message just arrived twice — does your design still do the right thing? Check your idempotency grasp.

You made operations retry-safe: at-least-once causes duplicates, idempotent operations repeat harmlessly, use keys and dedup, keep record-and-process atomic with a TTL.