Queues, Streams, Eventing
Message ordering: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the material stick.
Reconstruct the unit’s core mechanisms — total order vs partial order, per-partition FIFO, partition-key choice, the producer reorder hazard, and the survivability patterns — without looking back at the lesson.
- 01Why is total order across all messages a throughput tax rather than a free config option?
- 02What is partial order, and how do Kafka and SQS FIFO each express it?
- 03How do you choose the partition key, and what goes wrong with common bad choices?
- 04How can a Kafka producer reorder two messages on the same partition, and how was it fixed?
- 05Why can a correctly partitioned per-key FIFO stream still show you events out of order, and what defends against it?
- 06Why does adding partitions to a Kafka topic risk corrupting per-key ordering, and how do teams avoid it?
If you could reconstruct each answer from memory, you hold the unit’s spine: total order needs one serialization point and caps throughput, so you reach for partial order — per-key FIFO via Kafka’s partition key or SQS FIFO’s MessageGroupId. Choose the key as the consistency boundary, verify the producer is idempotent so it cannot reorder at the source, and remember that at-least-once redelivery, DLQ replay, and repartitioning all break order even when partitioning is correct. The durable consumer is idempotent, prefers commutative effects, and version-guards against stale updates.