Fire and Forget
A communication pattern where the sender dispatches a message and doesn't wait for or expect a response. Used for logging, analytics events, and non-critical notifications.
What is Fire and Forget?
In short
Fire and forget is a messaging pattern where the sender dispatches a request or message and immediately moves on without waiting for, or even expecting, a response. It trades delivery guarantees for speed, so it fits non-critical work like logging, analytics events, and notifications where losing an occasional message is acceptable.
What Fire and Forget Means
In a normal request, the caller sends data and then blocks, holding the connection open until a reply comes back. That reply tells the caller whether the work succeeded. Fire and forget removes that second half. The sender pushes the message out and returns control to its own code right away, treating the send as done the moment the message leaves the building.
Because there is no acknowledgement, the sender never learns if the receiver got the message, processed it, or crashed. This is the deliberate trade. You give up confirmation to gain a sender that is fast and never stuck waiting on a slow or dead downstream service.
The name comes from artillery. You aim, fire, and do not track the shell. In software the same idea applies to a UDP packet, a queued background job, an analytics beacon, or an async method call that returns nothing useful.
How It Works Under The Hood
At the network level, UDP is the classic fire and forget transport. The sender writes a datagram to a socket and the operating system hands it to the network. There is no handshake, no retransmission, and no ACK. Contrast that with TCP, which spends a round trip on a handshake and waits for acknowledgement of every segment.
At the application level, the pattern usually rides on a message broker or an in-process queue. A web server handling a checkout might write an event like order.placed to Kafka or RabbitMQ and respond to the user immediately. A separate consumer reads that event later to send the confirmation email. The user request finishes in milliseconds because it never waits for the email to send.
In code, fire and forget often looks like starting a task without awaiting it. In Node you might call sendAnalytics(event) without await. In Go you launch a goroutine. The danger is that if the process exits or the queue is full, that work silently disappears, which is why durable brokers are preferred over raw in-memory tasks for anything you care about.
When To Use It And The Trade-Offs
Reach for fire and forget when the message is not essential to the outcome the user is waiting on, and when an occasional loss does not break anything. Logging, metrics, page-view tracking, cache invalidation hints, and best-effort push notifications all fit. If your analytics drops 1 in 10,000 events, your dashboards are still useful.
Do not use it for anything that must happen exactly once or that the caller depends on, like charging a card, transferring money, or persisting an order. For those you need a request-reply pattern or at-least-once delivery with acknowledgements, retries, and idempotency keys so a retry does not double-charge.
The core trade-off is latency and decoupling versus reliability and observability. You get a snappy, loosely coupled system where the sender does not care if the receiver is down. You lose the ability to know if work completed, and debugging gets harder because failures are silent. Many teams split the difference: fire and forget into a durable queue, so the send is fast but the message survives a consumer crash and gets retried.
Where it is used in production
Apache Kafka
Producers can run with acks=0, meaning they send a record and never wait for the broker to confirm it was written, the highest-throughput fire and forget mode.
StatsD and Datadog
Metrics agents emit counters and timers over UDP, accepting that a lost packet just means one missing data point rather than blocking the application.
RabbitMQ
Publishing without publisher confirms is fire and forget, used for non-critical notifications where speed matters more than guaranteed delivery.
Google Analytics and Meta Pixel
Browser tracking beacons fire off page-view and event pixels without the page waiting on or checking the response.
Frequently asked questions
- Is fire and forget the same as asynchronous?
- Related but not identical. Async means the caller does not block while waiting. Fire and forget is a stronger choice where the caller does not wait and does not even collect a result later. You can have async request-reply where you await a future for the answer; fire and forget skips the answer entirely.
- What is the difference between fire and forget and request-reply?
- Request-reply sends a message and waits for a response that confirms the outcome, so the caller knows if it worked. Fire and forget sends and returns immediately with no confirmation, trading certainty for speed and decoupling.
- Does fire and forget guarantee the message is delivered?
- No. By definition there is no acknowledgement, so a message can be dropped by the network, a full queue, or a crashed consumer and the sender never finds out. If you need delivery guarantees, use acknowledgements and retries instead.
- How do I make fire and forget more reliable without losing its speed?
- Fire into a durable message broker like Kafka or RabbitMQ rather than an in-memory task. The send stays fast, but the broker persists the message so a consumer crash does not lose it, and a separate worker can retry processing later.
- Why does UDP count as fire and forget?
- UDP sends datagrams with no handshake, no acknowledgement, and no retransmission. The sender writes the packet and moves on with no idea whether it arrived, which is the exact shape of fire and forget at the transport layer.
Learn Fire and Forget hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Fire and Forget as part of a larger topic.
See also
Related glossary terms you might want to look up next.
Asynchronous
A communication model where the caller fires off a request and continues without waiting for a response. Essential for non-blocking I/O and event-driven systems.
Message Queue
A buffer that stores messages between producers and consumers. Messages are processed one by one, in order. Think of it as a to-do list for your services.
Pub/Sub
A messaging pattern where publishers send messages to topics, and subscribers receive messages from topics they care about. Publishers don't know who's listening.
Latency
The time delay between sending a request and getting a response. Amazon found every 100ms of extra latency costs 1% in sales.
Throughput
The number of operations a system can handle per unit of time. Think of it as how many cars a highway can move per hour.
Bandwidth
The maximum amount of data that can be transferred over a network in a given time. It's the width of the pipe, not how fast the water flows.