Does Strict Global Tweet Ordering Require Compromising Availability in Snowflake-Based Write Paths?

Assuming a standard 64-bit Snowflake layout with timestamp, worker ID, and sequence components, Twitter's publicly described architecture uses these identifiers as time-ordered keys intended to make tweet writes idempotent during retries. The ID generator itself does not track previous write attempts, leaving deduplication to the application or database layer.

A documented tension remains between enforcing strict global ordering of tweets and maintaining high availability across geographically distributed data centers. Because Snowflake IDs depend on synchronized clocks, significant drift can introduce collisions or ordering anomalies that complicate retry semantics. When a client retries a write across datacenter boundaries, the interaction between worker clock drift, caching layers, and persistent stores raises unresolved questions about ordering guarantees.

Does strict global tweet ordering require compromising availability in Snowflake-based write paths? What idempotency boundaries should exist between the ID generator and downstream storage when clock drift is detected across datacenters? Which consistency model best preserves duplicate suppression without sacrificing partition tolerance?