From c4c92d9c4f7c9a055f8cb4ac2f2d9153c7ae6fcb Mon Sep 17 00:00:00 2001 From: Ginger Collison Date: Fri, 4 Oct 2019 11:24:20 -0500 Subject: [PATCH] Update acks.md --- developer/concepts/acks.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/developer/concepts/acks.md b/developer/concepts/acks.md index 9d8576e..8b0502c 100644 --- a/developer/concepts/acks.md +++ b/developer/concepts/acks.md @@ -2,6 +2,6 @@ In a system with at-most-once semantics, there are times when messages can be lost. If your application is doing request-reply it should use timeouts to handle any network or application failures. It is always a good idea to place a timeout on a requests and have code that deals with timeouts. When you are publishing an event or data stream, one way to ensure message delivery is to turn it into a request-reply with the concept of an acknowledgement message, or ACKs. In NATS an ACK can simply be an empty message, a message with no payload. -![acks](/assets/images/acks.svg) +![](/assets/images/acks.svg) Because the ACK can be empty it can take up very little network bandwidth, but the idea of the ACK turns a simple fire-and-forget into a fire-and-know world where the sender can be sure that the message was received by the other side, or with a [scatter-gather pattern](reqreply.md), several other sides.