You're designing a system to send password-reset emails: an API call enqueues a 'send reset email' task, and a worker pool sends it exactly once soon after. Would you reach for a destructive-read queue like SQS or an event log like Kafka, and why?

## The three questions that decide it The decision hinges on three questions: 1. Is this a **command** (do this exactly once) or a **fact** (this happened, and multiple parties may care about it now or later)? 2. Do you need multiple independent consumers, now or foreseeably? 3. And is replay something you want, or something you must actively prevent? Sending a password-reset email is a command with one logical consumer, and replay is undesirable - all three point toward a queue. ## Why the mechanism favors a queue The mechanism argument favors a queue directly: SQS or RabbitMQ's core primitives - ack-to-delete, visibility timeout with automatic redelivery, and a dead-letter queue after a configured `maxReceiveCount` - exist precisely to implement 'try this task, retry on failure, give up after N tries and alert a human' with minimal custom code. A worker pool of N instances naturally load-balances via competing consumers, with no partition-key design required. ## Why a log fits badly here A log would be awkward here for the opposite reasons. - To prevent double-sends on a log, you'd need to persist 'have I already sent for offset X' somewhere yourself - essentially reinventing acking on top of the log. - And you'd need to reason about consumer-group rebalances potentially reprocessing a task mid-send. - You'd gain none of the log's headline benefits, since nobody else should be reading 'send email' tasks, and replay here is a bug magnet rather than a feature. ## The counter-scenario that flips it A counter-scenario sharpens the boundary: if instead the event were 'PasswordResetRequested' published as a fact (not a task), and consumed independently by an email-sending service, a security anomaly-detection service, AND an audit-log archiver, that's now multiple independent consumers reacting to one occurrence - textbook log territory. The tell is whether new, unforeseen consumers might reasonably want the same occurrence in the future; a queue's 'do this job' framing assumes a fixed, known consumer, while a log's 'this happened' framing keeps the door open. ## What each choice costs There are real costs on both sides of this specific choice. - **Choosing a queue** means no free audit trail (you'd add application-level logging separately) and no easy path to adding a new service that reacts to reset requests later without extra plumbing. - **Choosing a log** instead for this case would cost extra engineering to prevent resends (a dedup store or offset-based idempotency key), harder-to-reason-about retry semantics (hand-rolling a DLQ equivalent), and paying for retention storage of data you'd rather not keep around - reset emails often carry sensitive tokens, and a log holding those for a multi-day retention window is a larger PII exposure surface than a queue that deletes the payload the moment it's sent. ## The resolution The resolution for this specific case: use SQS. - The API handler enqueues a task containing the user ID, reset token, and timestamp. - A worker pool of email senders additionally enforces idempotency by checking a short-TTL key in a fast store (e.g., Redis) keyed on the reset token before sending, defending against the rare double-delivery during a visibility-timeout race. - Failures retry up to a configured limit then land in a DLQ that pages on-call. - And the token itself expires quickly, so even a very late redelivery is naturally harmless rather than dangerous.