Interview questions

Interview questions (with the counter-questions you'll get)

Q1. Why would you put a message queue between two services?

They're testing: the core motivation.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** To decouple them in time and failure. The producer responds quickly without waiting for slow work; the consumer can be down without failing the producer; spikes are absorbed and drained at a steady rate; and each side scales independently. The cost is eventual completion, more infrastructure, and having to handle duplicates and ordering.
3
4**Counter-questions:**
5- *"When wouldn't you?"* → When the caller needs the result immediately to continue, like checking stock or charging a card during checkout.
6
7**Trap:** using a queue for something the user is waiting on.

Q2. Explain at-most-once, at-least-once and exactly-once delivery.

They're testing: the classic guarantee question.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** At-most-once: ack before processing; crashes lose messages. At-least-once: ack after processing; crashes cause redelivery and duplicates. Exactly-once delivery isn't achievable end to end in general; systems give exactly-once effect by combining at-least-once delivery with idempotent processing, or within scoped features like Kafka transactions and SQS FIFO deduplication.
3
4**Counter-questions:**
5- *"Doesn't Kafka have exactly-once?"* → Within Kafka (read, process, write back to Kafka, committing offsets atomically). Side effects outside Kafka, like a database write or an SMS, still need idempotency.
6
7**Trap:** claiming a broker gives exactly-once processing with no work on your side.

Q3. How do you make a consumer idempotent?

They're testing: practical correctness.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Use a natural or business key (order ID plus action) and record it in a processed table with a unique constraint, in the same transaction as the effect, so duplicates fail and are skipped. Prefer naturally idempotent operations like setting a status, use conditional updates, and pass idempotency keys to downstream APIs.
3
4**Counter-questions:**
5- *"Why not just keep message IDs in memory?"* → Memory is lost on restart and isn't shared across workers; and a producer retry can create a new message ID for the same business event.
6
7**Trap:** de-duplicating only in memory on one worker.

Q4. What is a visibility timeout, and how do you choose it?

They're testing: broker mechanics.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** When a consumer receives a message, it's hidden from others for the timeout; acking deletes it, otherwise it reappears for another consumer. Set it longer than the slowest normal processing time, extend it for long jobs, but not so long that crashed workers' messages wait ages to retry.
3
4**Counter-questions:**
5- *"What if processing time varies wildly?"* → Extend visibility while working (a heartbeat), or split the job into smaller steps.
6
7**Trap:** leaving the default when jobs can take longer.

Q5. What is a dead-letter queue, and what do you do with it?

They're testing: operational maturity.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** A queue that receives messages that failed processing too many times, so poison messages don't block or loop forever. Alert when it's non-empty, inspect messages, fix the code or data, then redrive them to the main queue. Keep retention long enough to do that.
3
4**Counter-questions:**
5- *"Transient vs permanent failures?"* → Retry transient ones with backoff; detect obviously permanent ones (validation errors) and dead-letter them immediately.
6
7**Trap:** a DLQ with no alert.

Q6. How do you guarantee message ordering?

They're testing: ordering vs parallelism.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Usually you need order per entity, not globally. Partition by key (Kafka key, SQS FIFO message group ID) so all messages for one entity go to one partition, read by one consumer in order. Different keys still process in parallel. Alternatively, design consumers to tolerate disorder with versions.
3
4**Counter-questions:**
5- *"What does a stuck message do?"* → It blocks its partition or group; you need timeouts and a DLQ to unblock it.
6
7**Trap:** asking for global ordering, which kills parallelism.

Q7. Kafka vs RabbitMQ (or SQS): when do you use which?

They're testing: tool judgement.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Kafka is a distributed log: messages are retained, each consumer group reads everything at its own offset, replay is possible, ordering is per partition, and throughput is very high. It suits event streams with many readers. RabbitMQ and SQS are queues: messages are deleted after ack, with per-message features like delays, priorities and dead-lettering. They suit task distribution.
3
4**Counter-questions:**
5- *"Can you use Kafka as a job queue?"* → Yes, but retries, delays and per-message DLQs need building, and a slow message blocks its partition.
6
7**Trap:** "Kafka is just a faster RabbitMQ."

Q8. Your queue keeps growing. What do you do?

They're testing: backpressure and scaling.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** First, find out why: arrival spike, slower consumers, a failing downstream, or a poison message being retried. Then scale consumers if the downstream can take more load; fix or bypass the slow downstream; shed or deprioritise low-value work; and apply backpressure upstream with a bounded queue and 429s if it's sustained. Alert on queue depth and the age of the oldest message.
3
4**Counter-questions:**
5- *"Why age, not just depth?"* → Depth depends on traffic; age tells you directly how late work is.
6
7**Trap:** adding consumers without checking the downstream limit.

Q9. How would you schedule "cancel the order if unpaid after 15 minutes"?

They're testing: delayed jobs.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Enqueue a delayed message (SQS delay up to 15 minutes) or store the job with a run-at time in a table or Redis sorted set, with a poller that moves due jobs to a work queue. When it runs, re-read the order and cancel only if still unpaid, with a conditional update so a payment arriving at the same moment wins cleanly.
3
4**Counter-questions:**
5- *"Millions of such jobs?"* → A sorted store indexed by run time, sharded, and polled in batches; or bucket jobs by minute.
6
7**Trap:** cancelling without re-checking the current state.

Q10. How do you publish a message reliably when you also update the database?

They're testing: the dual-write problem.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Writing to the database and then the queue can fail between the two, losing the message, or the reverse, publishing an event for a change that rolled back. Use the outbox pattern: write the change and an outbox row in one transaction, then a relay publishes outbox rows to the queue and marks them sent. Delivery is at-least-once, so consumers must be idempotent. Chapter 23 covers it in detail.
3
4**Counter-questions:**
5- *"Alternative?"* → Change data capture reading the database log.
6
7**Trap:** "save, then publish" with no handling for a crash in between.
8
9---
10
11## Practice coverage
12
13Every section in this chapter is tested at least once.
14
15| Section | Tested by |
16|---|---|
17| 22.1 Producers and consumers | Level 3.1, Level 5.1, Q1 |
18| 22.2 Why async | Level 1A, Level 2.1, Q1 |
19| 22.3 Delivery guarantees | Level 1B.1, Level 1B.2, Level 3.2, Q2 |
20| 22.3.1 At-most-once | Level 1B.1, Level 3.2, Q2 |
21| 22.3.2 At-least-once | Level 3.2, Level 4, Q2 |
22| 22.3.3 Exactly-once | Level 5.2, Q2 |
23| 22.4 Acks and visibility timeouts | Level 3.1, Level 4, Q4 |
24| 22.5 Retries and DLQs | Level 1B.3, Level 2.4, Level 5.5, Q5 |
25| 22.6 Idempotent consumers | Level 1B.2, Level 3.3, Level 4, Q3 |
26| 22.7 Ordering | Level 1B.4, Level 5.4, Q6 |
27| 22.8 Backpressure | Level 2.2, Level 5.3, Q8 |
28| 22.9 Scaling consumers | Level 1B.5, Level 2.3, Level 2.5, Q8 |
29| 22.10 Log vs queue | Level 2.5, Level 3.4, Q7 |
30| 22.11 Delayed jobs | Level 3.5, Q9 |
31
32---

22. Message Queues