Practical framework / 5 MIN READ
Make a retry preserve the identity of the original event
Separate a repeated delivery from a genuinely repeated customer action.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-06
Networks and integrations can resend events after uncertain delivery. A robust counting contract recognizes retries without collapsing separate legitimate actions, and verifies the behavior at every destination that uses the data.
What you will leave with: Create an event identity and retry specification with end-to-end duplicate tests.
Use this when
- Purchase events inflate after a connector recovery.
- Browser and server reporting both describe the same business action.
This lesson addresses delivery semantics after an event is defined, not the initial event naming or trigger specification.
Define the identity of the business action
Choose what makes two deliveries represent the same event. A stable order-event identifier may work for one transaction transition; a pageview needs a different identity. Avoid using only customer ID, timestamp rounding or payload equality, because separate actions can share those values.
Record when the identifier is created and how it persists through retries. A retry of the same action should preserve its intended identity. A genuinely new action needs a new identity even if its content matches. Corrections to an existing business fact may require a distinct update operation rather than another creation event.
Inspect each system’s deduplication rules
Twilio Segment documents deduplication using messageId rather than payload contents, with processing limits that differ across destinations. That is a useful reminder to read the actual contract at every stage. A provider’s bounded deduplication behavior is not a universal exactly-once guarantee.
Map client, server, transport, warehouse and advertising destinations. Identify where identities are generated, transformed or discarded. A random new identifier assigned on each retry defeats identity-based deduplication. Conversely, reusing one identifier across unrelated legitimate events can silently discard real activity.
Test ordinary and delayed retries
Build a synthetic sequence containing an original event, an immediate retry, a delayed retry, a separate identical-looking action and a correction. State the expected count and state at each destination. Test uncertain outcomes where the sender timed out after the receiver accepted the event.
Inspect downstream behavior, not only ingestion success. A warehouse may deduplicate while a triggered notification or external conversion system already acted twice. Keep tests in approved environments and avoid sending real purchases, customer messages or charge-triggering events merely to exercise the pipeline.
Govern recovery and monitoring
Document a safe replay procedure, including supported identities, lookback limits and destination side effects. Before replaying a production batch, check whether it already executed and obtain authorization for any consequential external actions. Never assume a failed response proves nothing happened.
Monitor duplicate identity rates and unexplained count differences, with sanitized diagnostics. Retain enough permitted metadata to investigate without storing sensitive payloads unnecessarily. Revisit the contract when an SDK, server integration or destination changes. A retry policy is part of the business measurement definition, not just an infrastructure detail.
Make the reasoning concrete.
A hypothetical checkout emits one purchase event with identity P-41. A timeout causes two retries. If each retry receives a new identity, a destination may count three purchases. If identity P-41 is preserved under its supported deduplication contract, the intended count remains one.
Generate identity at each send
Opening: Treat every delivery attempt as new.
Hypothesis: The transport records are distinct.
Risk: Business outcomes can be multiplied.
Preserve action identity
Opening: Reuse P-41 for retries and issue a new identity for a genuinely new purchase.
Hypothesis: The receiver can distinguish retries from new actions.
Risk: Its time limits and side effects still require testing.
Verify one business outcome at every intended destination, including delayed replay cases. Do not infer success from a single clean warehouse total.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Identity
What defines one business event?
Retry
Where is its identity preserved or changed?
Destinations
What deduplication and side-effect rules apply?
Fixture
Which retry, new-action and correction cases must pass?
Recovery
How is uncertain prior execution checked before replay?
Watch for the wrong conclusion.
- Assigning a new identity to every retry.
- Deduplicating by customer alone.
- Assuming all destinations behave like the warehouse.
- Replaying an uncertain consequential action without checking its outcome.
Your next action
Write a five-case retry fixture and verify the intended count across the full approved measurement route.
Sources & scope
Frameworks, worksheets and hypothetical examples are original editorial synthesis. Linked primary sources support only the stated concepts. Source checking is not an independent audit of effectiveness. No named human author or reviewer is claimed.
- Twilio Segment: Handling Duplicate Data →Primary technical documentation · Supports: Documents messageId-based deduplication and distinct processing limits by destination. The lesson does not claim universal exactly-once delivery or use a provider guarantee as a substitute for downstream tests.