Exactly once delivery
Trade off:
- lower throughput
- higher latency
- requires tracking message identifiers to ensure the message has not already been handled
Pros:
- you can still do retries when the message is delivered but the consumer fails for some reason
- consuming system probably needs to work in an idempotent manner (if message is retried and succeeds it will have same effect as it would have if it succeeded on first try)
- message is only delivered once
At least once delivery
Pros:
- fast
- cheap
Cons:
- message can be delivered more than once
Latency and throughput limits of different queues
Kafka vs SQS
Kafka:
- Faster: ~1ms
- 1:1 and broadcast
- Guarantees ordering within a partition. A partition could get bogged down with load though, so cross partition ordering not maintained.
- Can not guarantee ordering across partitions under any circumstances, unless you only have 1 partition (which has performance limitations)
- Consumers poll the queue for messages, no persistent connections.
SQS:
- Slower: ~10 ms
- Just 1:1
- Standard queue (order NOT guaranteed)
- millions of TPS
- FIFO queue (order guaranteed):
- up to 300 TPS when using just 1 message group (ensures global ordering of messages)
- up to 3k TPS when using batching and multiple message groups
Redis Pubsub
< 1 ms latency
fully in memory
push based
typically used for online status notification feature
Doesn’t guarantee ordering for multiple consumers. Does guarantee it if only 1 consumer.
Use when:
- Extremely fast latency needed (<1 ms)
- Persistence not required
- Usecases:
- notifications to apps
- status update of users
- When you want easy impl (no infra set up)
Bad for:
- Durability
- Ordering required for multiple consumers
Redis Streams
Does consumer poll based message delivery
Allows multiple consumers to consume from stream. Each message only goes to 1 consumer though.
Always guarantees message order
SNS vs Kafka
Kafka topics, partitions, consumer groups, and ordering.
Can have multiple partitions per topic. Each message goes to exactly 1 partition (usually based on hash). Each partition guarantees ordering.
If multiple consumer groups reading from the same partition, order is not guaranteed across consumer groups though. The messages will just come out of the partition in order, but consumer groups may process at different rates.
The only way to ensure ordering in Kafka is to only have a topic with 1 partition, so therefore it usually would only make sense to have and 1 consumer group with 1 consumer in it.
