Deduplicate SMS delivery events without losing evidence

Published by OPEN RAMBO. The engineering patterns and pseudocode illustrate designs, not a documented product API. Numerical examples are illustrative.

Choose the right identity

Prefer an upstream message identifier scoped to the original order and provider. If none exists, use a carefully defined keyed digest of stable fields rather than a plain hash of a short code. Short codes have a tiny search space and plain hashes do not protect them.

Separate replay from new content

A second message can legitimately arrive for the same order. Do not use order_id alone as the message key. Preserve receipt timestamps and sequence metadata while applying a data-minimization policy to message bodies. The UI should not create multiple success notifications for one event.

Keep settlement independent

Message deduplication does not replace financial idempotency. A duplicate delivery must not debit again, and a new message must not automatically create a new paid order. Make each business action reference the original order contract.

Illustrative implementation

unique_key = (provider_id, order_id, message_id)
insert_event_if_absent(unique_key)
# Never use a raw OTP as an analytics identifier.

Acceptance check

Replay one event repeatedly, then send a distinct event for the same order. Expect one record for the replay and a separate second event.

Read next

• Migrate SMS suppliers without orphaning old orders
• Use circuit breakers without multiplying SMS purchases