Senior · Redis with Go
Streams, pending entries and idempotency
When should a consumer acknowledge a Redis Stream message?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
A consumer group tracks delivered pending entries. Acknowledge after the durable business action succeeds; acknowledging before it risks losing work if the process crashes.
Crashing after the action but before ACK permits redelivery. Reclaim abandoned pending entries according to idle time and ownership policy, and make the side effect idempotent with a durable event ID.
Retention/trimming, pending recovery, poison messages and stream persistence are separate policies. Bound retries and route terminal failures for inspection. Consumer groups are a delivery mechanism, not a promise that any external effect occurs exactly once.
Common trap
Reading a message is not the same as successfully processing or acknowledging it.
Try it
A worker updates the database then dies before XACK. How does the replacement avoid a double update?
Worked solution
Reclaim or receive the pending event and atomically deduplicate its stable ID with the database mutation. If already applied, acknowledge it again. A memory-only set loses that evidence on restart.
Change the constraint
How can aggressive trimming interfere with recovery of old pending messages?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.