Async & Message Queues — Series 2

Preview — 3 of 10 questions

A Kafka-style topic is split into multiple partitions for scalability. Producers send events for the same orderId to the topic. Why doesn't Kafka guarantee global ordering across the whole topic, and how is per-key ordering still achieved?

AKafka guarantees strict global ordering across all partitions automatically, with no extra configuration needed

BOrdering is never guaranteed by Kafka under any configuration, making it unsuitable for any order-sensitive use case

CSince different partitions are consumed independently and in parallel, there's no single, agreed-upon order across the entire topic — messages in different partitions can be processed in any relative order. However, Kafka does guarantee ordering within a single partition, so producers key messages by something like orderId, ensuring all events for the same order always land in the same partition and are therefore delivered in the order they were produced

DPer-key ordering is only possible if the topic has exactly one partition, defeating the purpose of partitioning entirely

A payment-processing consumer reads from a queue that provides at-least-once delivery, meaning the same message might occasionally be delivered twice. How does making the consumer idempotent solve the problem this creates?

AIdempotent consumers solve the problem by refusing to process any message more than once, causing the second delivery to error out and crash the consumer

BMaking a consumer idempotent means designing its processing logic so that handling the same message multiple times produces the same end result as handling it once — for example, by checking a unique message/transaction ID against records already processed (and skipping if it's a duplicate) before applying the payment. This way, occasional duplicate deliveries from the queue don't cause double-charges or other repeated side effects

CIdempotent consumers can only be built using a NoSQL database, never a relational one

DIdempotency means the consumer processes messages twice as fast as normal

A service needs to update its own database and publish an event to a message broker as part of the same logical operation (e.g., save the order and notify shipping). Why is doing this naively (write to DB, then publish to the broker) risky, and what does the outbox pattern fix?

AThere's no risk at all — a database write and a message publish can always be wrapped in one atomic operation across two completely separate systems with no special handling

BThe outbox pattern means publishing the event before writing to the database, guaranteeing the event always arrives even if the database write later fails

CNaively performing the database write and the broker publish as two separate steps risks partial failure — the DB write could succeed while the publish fails (the event is lost), or vice versa. The outbox pattern fixes this by writing the event into an "outbox" table in the same local database transaction as the business data change (making both atomic together), then a separate background process reads unpublished outbox rows and reliably publishes them to the broker, retrying until it succeeds

DThe outbox pattern requires removing the message broker entirely and relying only on direct database writes

Answer all 10 questions (7 more), see explanations for every answer, and track your score.