Ordered delivery
A log keeps order only inside one partition. When messages go to 8 partitions with no key, the messages of one chat can arrive out of order. Keyed by conversation, all messages of a chat use one partition and keep their order.
See it on the board
The same traffic runs on two boards. The simulator measured both when this page was built.
| Measure | Goal | No key, messages spread over partitions | Keyed by conversation |
|---|---|---|---|
| Error rate | under 0.1% | 0% Pass | 0% Pass |
| Lost writes | none | 0 Pass | 0 Pass |
| Duplicates | none | 0 Pass | 0 Pass |
| Out of order | none | 288 Fail | 0 Pass |
| Queue lag | under 40 s | 28.5 s Pass | 28.5 s Pass |
| Monthly cost | 44 USD/mo | 44 USD/mo | |
| p99 latency | 134 ms | 134 ms |
Key numbers
| Number | Value |
|---|---|
| Messages per second, one log | 100,000 ops/s |
| Log append, median | 2 ms |
| Log append, p99 | 10 ms |
13 deliveries · 10 payments applied · 0 charged twice
How it works
A chat needs order. If message 2 arrives before message 1, the conversation makes no sense. A log can keep order, but only inside one partition. A topic with many partitions spreads messages for speed, and across partitions no order is promised.
In the mini board phones send 200 messages/s. The log has 8 partitions, and a message without a key goes to any partition. Two messages of the same chat can land in two partitions and be read by two workers, in any order. The run counts 288 messages out of order.
A partition key fixes this. The sender sets the conversation ID as the key. The log hashes the key and always picks the same partition for it. All messages of one chat go through one partition and one worker, so they stay in order, and different chats still run in parallel.
There is a limit. One very busy chat sends all its load to one partition, and that partition can be slower than the rest. Also, when you change the number of partitions, keys move, and order can break for a short time.
Order is only one of three needs. A reliable send also needs an outbox so that no message is lost, and an idempotency key so that a retry does not repeat a message.
In the levels you key the messages and check the count of messages out of order.