Question 1

A Kafka topic must keep events for each order in order, and handle 100k events per second across many consumers. What do you do?

Accepted Answer

Use the order id as the partition key Kafka guarantees order only within a partition, and keying by order id sends all events of an order to one partition while different orders spread across many. One partition preserves order but caps throughput at one consumer. Sorting by timestamp in consumers breaks with clock skew and events in flight. Extra consumers beyond the partition count sit idle.

Question 2

A Kafka topic has 12 partitions. A classic consumer group (not a share group) has 20 consumers. How many consumers receive messages?

Accepted Answer

12 Each partition is assigned to exactly one consumer in a group, so at most 12 are active and 8 are idle standbys. 20 assumes partitions are shared. 8 is the idle count. 1 confuses consumer groups with a single consumer. Kafka share groups (KIP-932) are different: they let more consumers than partitions receive records.

Question 3

Producers enqueue faster than consumers can process for hours at a time. The queue keeps growing and end to end latency is now hours. What is the right response?

Accepted Answer

Bound the queue and push back on producers while scaling consumers A queue smooths bursts but cannot fix sustained overload; backpressure (rejecting or slowing producers with a clear signal) keeps latency bounded while consumers scale. An unbounded queue just converts overload into unbounded latency. Dropping silently loses data no one knows about. More producer retries add load.

Question 4

One malformed message makes the consumer throw every time, so it is redelivered forever and nothing behind it is processed. What is the standard fix?

Accepted Answer

After N failed attempts move it to a dead letter queue and keep going A dead letter queue isolates poison messages for inspection and replay while the main flow continues. Retrying forever keeps blocking. Skipping loses the message and the evidence. Restarting redelivers the same message.

Question 5

An SQS consumer takes 5 minutes per job and deletes the message on success. The visibility timeout is 30 seconds. Jobs are processed twice while the first run is still going. Why?

Accepted Answer

The message became visible again after 30 seconds and another consumer received it Visibility timeout hides a received message only for that long; if processing is longer, the message reappears. Set it above the processing time or extend it while working, and keep handlers idempotent since standard queues are at least once anyway. Standard queues do redeliver. There is no 1 second ack rule. Both queue types support delete.

Question 6

A consumer uses Kafka transactions (exactly once semantics) and sends one email per event. Can a user get the email twice?

Accepted Answer

Yes: exactly once covers Kafka reads and writes, not the email, so dedupe by event id Kafka EOS makes consume, process and produce atomic within Kafka. If the consumer sends the email and crashes before committing, it reprocesses and sends again. External side effects need their own idempotency, such as recording the event id with the send. acks=all is about durability. Producer idempotence prevents duplicate writes to Kafka, not duplicate emails.

Question 7

An order service must write the order row and publish an OrderCreated event. Neither may happen without the other. What is the standard pattern?

Accepted Answer

Insert the event into an outbox table in the same transaction, and a relay publishes it The outbox makes the event part of the local database transaction; a relay or CDC publishes it at least once, so consumers dedupe. Most brokers do not take part in 2PC with your database, and 2PC adds blocking failures. Publish first leaves an event for an order that may fail to commit. Publish after commit loses the event if the process dies in between.

Question 8

A client charges a card, times out before seeing the response and retries. The charge must happen once. What do you build?

Accepted Answer

An idempotency key stored with the result, returning the stored result on retry The client sends a unique key; the server records it atomically with the outcome and replays the saved response on retry, which is how Stripe works. Amount and timestamp collide for real repeat purchases and differ across retries. Kafka EOS does not cover an external charge. Card networks do not take part in your 2PC.

Question 9

A request reuses an idempotency key from an earlier request, but the amount is different. What should the API do?

Accepted Answer

Return an error because the parameters do not match the original request Stripe compares the new parameters with the original and errors on mismatch, since reusing a key for a different operation is a client bug. Processing it defeats the key. Returning the old result hides the bug and the client thinks it charged a new amount. Overwriting breaks the guarantee for the original request.

Queues and idempotency system design questions

More system design topics

Practise these on your commute