Message Queues & Streaming • Message Ordering & PartitioningEasy⏱️ ~2 min
Message Ordering Scope: Partitions vs Global Order
Message ordering in distributed systems is guaranteed only within a partition, not across the entire system. A partition is an append-only, ordered log where messages maintain strict First In First Out (FIFO) semantics. Producers use a deterministic hash function on a key (like user ID or order ID) to assign messages to specific partitions, ensuring all events for the same key land in the same partition in sequence.
Consumers in a consumer group process partitions exclusively: at any moment, only one consumer reads from a given partition. This single reader model ensures sequential processing and preserves the order that messages were written. The tradeoff is clear: you get strong ordering guarantees per partition but zero ordering guarantees across different partitions.
Global ordering across all messages requires either a single partition or a consensus based log, both of which create hard throughput bottlenecks. A single partition can only be processed by one consumer at maximum speed, capping your entire system throughput to that one consumer's processing rate. Consensus protocols add at least one Round Trip Time (RTT) of coordination per batch, pushing cross region p99 latencies into the 100 to 300 millisecond range.
Most production systems at scale choose per key ordering via partitioning rather than global order. LinkedIn processes trillions of messages daily using per member partitioning: all activity for member ID 12345 goes to the same partition, maintaining per user ordering while processing millions of users concurrently across thousands of partitions.
💡 Key Takeaways
•Ordering is scoped to partitions only. Each partition maintains strict FIFO order, but messages across different partitions can be interleaved in any sequence.
•Single consumer per partition rule ensures sequential processing. Consumer groups assign each partition to exactly one consumer at any moment to preserve order.
•Global ordering requires single partition or consensus, capping throughput. One partition limits you to one consumer's processing speed; consensus adds RTT coordination overhead per batch.
•Production systems prefer per key ordering at scale. LinkedIn runs thousands of partitions processing trillions of messages daily, maintaining per user order while enabling massive parallelism.
•Partition assignment uses deterministic hashing. hash(key) mod partition_count maps the same key to the same partition consistently, ensuring related messages stay together in order.
📌 Examples
LinkedIn partitions by member ID: all profile updates, posts, and activity for user 12345 go to partition hash(12345) mod 1000, preserving per user event order while processing millions of users in parallel
Amazon Kinesis shards: each shard handles up to 1 MB/s writes and 2 MB/s reads with ordering per partition key; scaling from 10 to 100 shards increases total throughput 10x while maintaining per key order
Banking transactions: account 9876 balance updates must be ordered (deposit before withdrawal check), so all transactions for account 9876 are keyed to the same partition ensuring sequential processing