Fire-and-Forget Pattern

You write a letter, drop it in the mailbox, and walk away. You don't stand there waiting for the postal service to confirm they picked it up. You don't wait for the recipient to read it. You trust that the system will handle delivery eventually, and you move on with your day.

That's fire-and-forget. The sender dispatches a message and immediately continues execution. There's no response. No acknowledgment. No waiting. The sender's responsibility ends the moment the message leaves its hands.

This sounds reckless, but it's the right pattern for a surprising number of scenarios. When you log an analytics event, do you need to wait for confirmation that the log was stored? When you send a "welcome" email after signup, should the user stare at a spinner until the email is actually delivered? When you emit a metric to your monitoring system, do you block your request handler until StatsD acknowledges receipt?

No. In all these cases, the sending service has more important work to do. The message is important, but not important enough to block the sender.

Fire-and-forget comes in two flavors:

Without a broker (UDP-style). The sender sends the message directly and doesn't wait for any acknowledgment. If the receiver is down, the message is lost. This is how StatsD metrics and syslog messages are typically sent, over UDP. Datadog's DogStatsD agent receives around 100,000 metric points per second on a single host this way. Speed matters more than guaranteed delivery.

With a broker (queue-backed). The sender pushes the message onto a queue and doesn't wait for the consumer to process it. The queue provides durability: if the consumer is down, the message waits. But the sender still doesn't get a processing result. Amazon SQS accepts a SendMessage call in about 2-5ms. Your API returns its response in that time, not the 500ms it might take to actually send an email.

// Fire-and-forget without broker
udpSocket.send(metricData, port, host); // returns immediately
// If the metric collector is down, this data is gone

// Fire-and-forget with broker
await queue.publish('email-tasks', { to: user.email, template: 'welcome' });
// Returns after the queue accepts the message, not after the email is sent

The key distinction: the sender confirms the message was accepted by the transport (the queue) but never waits for the message to be processed by the consumer. The consumer might process it 1 second later or 1 hour later. The sender doesn't know and doesn't care.