Asynchronous Communication

Synchronous means you ask, and then you wait for the answer before doing anything else. It is like calling a friend who says hold on. You stand there with the phone. If your friend takes ten minutes, you lose ten minutes.

Asynchronous means you leave a message and carry on. You drop a note in your friend's mailbox and go to the playground. Your friend reads it when they are free and does the job. In computers, the note is called a message, and the mailbox is a separate helper program, often called a message broker, that keeps messages safe until someone picks them up.

This makes a system calmer. A slow helper no longer slows down everyone who talks to it, and a helper that is restarting does not lose its mail, because the mailbox holds it.

The trade-off is that you do not get the answer right away. You only know your note was dropped off, not that the job is done. So notes fit jobs that can happen a little later, like sending a receipt email or shrinking a photo. Questions you need answered right now, like is this password correct, are still best asked on the phone.

A message queue is a line of notes waiting to be handled. Think of the homework tray on a teacher's desk. Kids (the senders) drop worksheets into the tray. A few classroom helpers (the workers) each take the sheet at the front and grade it. Each sheet is handed to one helper, not to all of them. Grown-ups call this competing consumers, because the helpers share out the work.

The tray is great at soaking up a rush. If thirty kids hand in work at the same moment, the sheets simply wait in the tray while the helpers keep a steady pace. If the pile keeps growing, we add more helpers. The queue turns a sudden flood into a calm stream.

When a helper finishes a sheet, it tells the tray done. That message is called an acknowledgement, or ack, and only then is the sheet thrown away. While a helper is working, the sheet is hidden from the other helpers. If the helper wanders off without saying done, maybe because its computer crashed, the sheet appears in the tray again after a set waiting time, so another helper can try. That is how no sheet gets forgotten.

The tray mostly hands out sheets in the order they arrived, first in, first out. With many helpers, though, that is not a promise. A quick helper can finish sheet 5 before a slow helper finishes sheet 4, and a sheet that comes back after a crash gets done late. If order really matters, related notes must wait in one line handled by one helper at a time, which is slower.

• Senders do not need to know which helper, or how many helpers, will do the work.
• A note that fails again and again is moved to a side pile called a dead-letter queue, so it cannot clog the line forever. A person looks at it later.
• Watch how long the line is. A line that only ever grows means the helpers cannot keep up.

In publish and subscribe, the sender does not hand a note to one helper. It makes an announcement. Picture the school speaker saying: soccer club, practice moves to the big field today. Every kid who joined the soccer club hears it, and each one acts on it in their own way.

The sender is called the publisher. The announcement channel, like soccer club, is called a topic. Everyone who signed up for that topic is a subscriber, and each subscriber gets its own copy of every message. The publisher does not know, or care, who is listening.

This is very handy in a shop. When someone places an order, the shop app publishes one message: new order. The email helper sends a receipt, the packing helper packs the box, and the points helper adds reward stars. Next month we can add a thank-you card helper that listens too, and the shop app does not change at all. Grown-ups call this decoupling: the pieces are not tied tightly together.

The trade-off is that nobody checks that every subscriber finished its job, because the publisher does not even know who they are. Each subscriber must handle its own failures and retries. Many systems also only deliver messages sent after a subscriber signed up, so a brand new subscriber can miss older news.

• Queue: share the work. Each message goes to one worker.
• Pub/Sub: share the news. Each subscriber gets its own copy.
• They are often combined: each subscriber gets its own queue, and several workers share that subscriber's copies.

Notes can get lost on the way. A network is like a windy playground: sometimes a paper airplane message just blows away. So every messaging system makes a promise about what happens then. The simplest promise is at-most-once.

At-most-once means the sender sends a message one time and never tries again. If it arrives, good. If it blows away, it is gone. A message can be lost, but it can never show up twice.

That sounds bad, but it is perfect for news that goes stale quickly. A thermometer that reports the temperature every second, or a game that sends where your character is standing many times a second, does not need old updates. A fresh one is right behind it, and resending an old one would be useless. Sending once is also the fastest and simplest choice.

At-least-once means the sender keeps sending until it hears back got it, which is the ack. It is like a mail carrier with a package that needs a signature. If nobody signs, the carrier comes back tomorrow with the same package.

This promise never loses a message, but it can deliver one twice. Imagine the receiver did sign, but the signed slip blew away on its way back. The carrier cannot tell the package was lost apart from the slip was lost, so it brings the package again. Now the receiver has two.

So receivers must be safe to repeat. Grown-ups call this idempotent: doing it twice gives the same result as doing it once. Pressing the elevator button twice still brings one elevator. Set my score to 10 is safe to repeat. Add 10 to my score is not, unless the receiver remembers which messages it has already handled.

At-least-once is the most common choice in real systems, because losing an order or a payment is usually much worse than receiving it twice and skipping the repeat.

Everyone wishes for exactly-once: every message arrives, and it arrives one time. Here is the catch. Over a network that can lose notes, the sender can never be sure whether its note or the got it reply was lost. If it sends again, it risks a double. If it does not, it risks a loss. So true exactly-once delivery is not possible by sending alone.

What real systems give is an exactly-once effect. The note may arrive twice, but the work happens only once. The most common way is at-least-once delivery plus a memory of what was done. Every message carries a unique ID, like a ticket number. The receiver writes down each ticket number it finishes, and when the same number shows up again, it says got it and skips the work. The ticket number and the work must be saved together in one step, or a crash between them could still cause a double.

Another way is to save the result of the work and the reading bookmark (which message I have read up to) together, all or nothing, in one transaction. Kafka transactions work like this: the output messages and the reader's bookmark are saved together. If a crash happens halfway, neither is kept, and the work is simply done again from the old bookmark.

The trade-off is extra effort: storing ticket numbers, slower saves, and more moving parts. And the promise only covers work inside the system. If the work is sending an email or charging a card through another company, that outside service must also be able to spot repeats.