Acknowledgements and ACKs - System Design

Hinzugefügt: 2026-05-15

[00:00:00]If you don't know this, you suck at system design. A producer will send a message over to the queue. That queue is going to send it to a consumer. The queue's job is to store that message.

[00:00:10]So, it has to give an acknowledgement back saying, "Hey, I've got that message. I've written it to disk. I'm not going to lose it." On the other side of the exchange, the job of the consumer is to process that message. So, when a consumer receives a message from the queue, it does not acknowledge it right away. It's going to send back that acknowledgement only once the task is done. If you send the acknowledgement before the task is done, you get what's called an at most once policy. You only do it at most once. That might mean you do the task zero times. The reason for that is because if there's a crash during the processing, well, you've already acknowledged it's done. So, you're not going to do it again. If you send the acknowledgement after you're done, you get what's called an at least once policy. You're going to process the message at least once. That means you will do it, but you might do it multiple times. So, that's obviously safe because you're going to process the message.

[00:01:10]However, you may end up with duplicate data. Cuz if a crash happens in the middle, you might do stuff multiple times. We don't want at most once because data may be lost. If you do at least once, then great, you'll retry until you get it. However, that data may be duplicated. If you truly want exactly once, then what you have to do is get at least once and use a trick called idempotency. That I've discussed in another video, so follow me for more.