Record the ordering evidence you actually have
Stripe does not guarantee delivery in generation order. Its event creation time is not a safe deduplication or ordering key. This synthetic example instead assumes a local source explicitly supplies a monotonic revision per record.
| Stored revision | Incoming | Decision |
|---|---|---|
| 12; inactive | Revision 11; active | Do not overwrite revision 12 |
| 12; inactive | Revision 13; approved reactivation | Apply according to lifecycle policy |
| No reliable revision | Two events with same timestamp | Read authoritative current state |
Handle a missing prerequisite without guessing
If a child event arrives before its parent, queue the dependency or retrieve the parent through a documented read. Keep the event identity so retries do not create a second child. An unavailable read leaves the task pending rather than inventing the parent.
Can comparing two second-resolution timestamps resolve their order?
Show the worked answer
Not if they tie or the source does not guarantee the ordering semantics. Use the source’s supported version/current-state mechanism and preserve both event identities.