Negative Acknowledgment (NACK) in Message Delivery

A negative acknowledgment (NACK or NAK) tells a sender or broker that a message was not successfully processed. Depending on the messaging system, it can trigger retry, redelivery, rejection, or dead-letter handling.

A NACK is the negative counterpart to an acknowledgment (ACK). An ACK generally indicates successful handling, while a NACK indicates that processing failed or the message cannot be accepted in its current form. The exact meaning is defined by the messaging protocol or client library.

In a Java backend, NACK behavior commonly appears in message consumers using brokers or messaging frameworks. A consumer may reject a message because of a transient dependency failure, invalid data, or another processing error. The broker can then decide whether to redeliver it, discard it, or route it elsewhere.

Retry behavior is important because a NACK does not inherently mean that retrying is safe. If processing has side effects, repeated delivery can create duplicates unless the consumer is idempotent. Transient failures are often suitable for retry, whereas permanently invalid messages may be better routed to a dead-letter queue.

Delivery semantics also matter. A NACK is typically part of an acknowledgment mechanism, but it does not by itself guarantee exactly-once processing. The application should define retry limits, backoff, idempotency, and failure-routing behavior according to the broker and business requirements.

Key points

• NACK indicates unsuccessful or rejected message processing.
• Redelivery after a NACK depends on the messaging system's semantics and configuration.
• Retries can produce duplicate side effects, so consumers should often be idempotent.
• Transient and permanent failures should be handled differently.
• Dead-letter queues can isolate messages that repeatedly fail processing.

Interview questions

How would you design retry handling for a Java message consumer?

I would first distinguish transient failures from permanent message or business errors. Transient failures could use bounded retries with exponential backoff, while permanent failures could be routed to a dead-letter queue. The consumer should be idempotent because redelivery can repeat side effects. I would also monitor retry counts, dead-letter volume, processing latency, and failure causes.

What is a negative acknowledgment in a messaging system?

A negative acknowledgment indicates that a consumer did not successfully process a message. The broker or messaging client can use that signal to reject, redeliver, or otherwise handle the message according to its configured semantics. It is the failure-oriented counterpart to an ACK. The exact behavior varies by messaging technology.

What can happen after a consumer sends a NACK?

Possible outcomes include redelivery, rejection, discard, or routing to a failure-handling destination. The outcome depends on broker configuration and the reason for failure. A transient error may justify another attempt, while malformed or permanently invalid data may need dead-letter handling. Retry policies should normally include limits or backoff rather than assuming every failure is temporary.

Why does NACK handling require idempotent consumers?

A NACK can lead to redelivery, so the same logical message may be processed more than once. If processing performs an external side effect, such as charging an account, a repeated attempt could duplicate that effect. An idempotent consumer makes repeated processing safe or detects that the operation has already been applied. This is especially important in at-least-once delivery systems.