Concept questionHard~9 min

Interview question

Why do queue consumers need to be idempotent, and how would you design that?

Design for at-least-once delivery with idempotent handlers

Explains why message handlers must tolerate duplicate delivery and how idempotency protects side effects.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Most practical queues give at-least-once delivery, which means a message can be delivered more than once. That can happen after worker crashes, lock expiration, network failure, or uncertain acknowledgement. I would design the handler so processing the same message twice does not create duplicate business effects. That usually means a stable message id, business idempotency key, or unique database constraint.

Full answer below

Practice focus

At-least-once delivery, retries, duplicate messages, idempotency keys, database constraints, and safe side effects.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Duplicate delivery is normal in an at-least-once system because work and acknowledgement cross separate failure boundaries. Handlers must make repeated delivery safe for every durable and external side effect.
Most practical queues give at-least-once delivery, which means a message can be delivered more than once. That can happen after worker crashes, lock expiration, network failure, or uncertain acknowledgement. I would design the handler so processing the same message twice does not create duplicate business effects. That usually means a stable message id, business idempotency key, or unique database constraint.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would make idempotency part of the business operation, not just a cache entry. For example, if a message creates an invoice, the invoice can have a unique key from tenant id plus source event id. If the handler sees the same key again, it returns the existing result or skips the already-applied change. External side effects like email or payment calls need their own idempotency keys or an outbox/inbox boundary.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I design idempotency around the durable side effect, not only around handler entry. Database changes and the inbox marker share one transaction, unique constraints protect business keys under concurrent duplicates, and external calls receive provider-supported idempotency keys where available. A crash after the side effect but before acknowledgement is an expected test case. Deduplication records outlive broker retry and replay windows, and metrics distinguish harmless duplicate deliveries from duplicate effects that escaped the boundary.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Assuming a message is processed exactly once.
Using an in-memory duplicate check that disappears on restart.
Making external side effects before recording idempotency.
Not keeping idempotency records long enough.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain at-least-once delivery.
Has no stable idempotency key.
Ignores duplicate external calls.
Treats retries as harmless without proof.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Where would you store idempotency state?
How would duplicate email sending be prevented?
What happens if the worker crashes after the database update?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Go deeper

Practice the next layer of the same subject.

Idempotent Upsert

Opening drill

Concept questionHard~9 min

Interview question

Why do queue consumers need to be idempotent, and how would you design that?

Design for at-least-once delivery with idempotent handlers

Explains why message handlers must tolerate duplicate delivery and how idempotency protects side effects.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

At-least-once delivery, retries, duplicate messages, idempotency keys, database constraints, and safe side effects.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Duplicate delivery is normal in an at-least-once system because work and acknowledgement cross separate failure boundaries. Handlers must make repeated delivery safe for every durable and external side effect.
Most practical queues give at-least-once delivery, which means a message can be delivered more than once. That can happen after worker crashes, lock expiration, network failure, or uncertain acknowledgement. I would design the handler so processing the same message twice does not create duplicate business effects. That usually means a stable message id, business idempotency key, or unique database constraint.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would make idempotency part of the business operation, not just a cache entry. For example, if a message creates an invoice, the invoice can have a unique key from tenant id plus source event id. If the handler sees the same key again, it returns the existing result or skips the already-applied change. External side effects like email or payment calls need their own idempotency keys or an outbox/inbox boundary.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I design idempotency around the durable side effect, not only around handler entry. Database changes and the inbox marker share one transaction, unique constraints protect business keys under concurrent duplicates, and external calls receive provider-supported idempotency keys where available. A crash after the side effect but before acknowledgement is an expected test case. Deduplication records outlive broker retry and replay windows, and metrics distinguish harmless duplicate deliveries from duplicate effects that escaped the boundary.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Assuming a message is processed exactly once.
Using an in-memory duplicate check that disappears on restart.
Making external side effects before recording idempotency.
Not keeping idempotency records long enough.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain at-least-once delivery.
Has no stable idempotency key.
Ignores duplicate external calls.
Treats retries as harmless without proof.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Where would you store idempotency state?
How would duplicate email sending be prevented?
What happens if the worker crashes after the database update?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Go deeper

Practice the next layer of the same subject.

Idempotent Upsert

Why do queue consumers need to be idempotent, and how would you design that?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

Why do queue consumers need to be idempotent, and how would you design that?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper