What happens when you send

Pressing send hands the issue to a queue and returns. The send itself runs in the background, in batches, at a rate a mail provider will accept, and every recipient is written down before a single message goes out.

This page is the walkthrough, in order. None of it needs managing, and none of it happens in the browser tab you pressed the button in.

The recipient list is frozen the moment you send

Issue Mint writes one row per active subscriber before anything is mailed, and that list is the send. A subscriber who joins two minutes later waits for the next issue rather than receiving a partly sent one.

Unsubscribed and undeliverable addresses are not in it. Neither are addresses on the platform suppression list, which is the record of hard bounces and complaints across every newsletter we send for: an address that has bounced for one publisher damages a shared reputation exactly as much when a different publisher mails it. Bounces and complaints covers how an address gets there. Those addresses are left out of your total as well as out of the send, so they cannot show up as failures on a report.

The issue is rendered once

The HTML, the plain text and the subject are rendered once per send rather than once per recipient, with the stylesheet folded down and every link rewritten for click tracking in one pass over the finished body.

Three things differ per reader, and all three are swapped into that finished body rather than triggering a re-render: the unsubscribe link, the open pixel, and the code that attributes a click to a subscriber. Rendering per recipient instead would turn a five thousand person send into an hour of pointless work. The render is kept for a day, and a send that finds it missing rebuilds it, because the same issue always renders the same way.

Batches, and how fast they go

Recipients are handed out in batches of 200, and several workers run batches at once.

The send rate is shared between those workers rather than applied to each of them, so the number is the aggregate and not a multiple of it. Hosted sending runs at 12 a second, held deliberately below what our provider allows so that a burst of retries cannot trip a throttle. Your own sending account starts at 10 a second until Issue Mint knows what its real quota is. A worker that arrives early waits for its turn, up to a minute, rather than sending ahead of the rate.

When something fails

Three different things can go wrong and each is treated differently, because they mean different things.

One bad address is marked failed with the reason the provider gave, and the send carries on. A throttle fails the batch and retries it, up to three attempts, waiting thirty seconds and then two minutes, with the addresses already sent to skipped on the way back through. A permanent problem, such as a credential that has been revoked or a provider account that has been suspended, stops the send between batches instead of grinding through five thousand rows marking every one of them failed. The issue is marked failed with the reason on it, and the addresses not reached stay waiting.

Suppression is also checked again for each batch, which catches the case that matters most: a reader who receives the issue at nine and reports it as spam while four thousand addresses are still queued behind them is not mailed anyway.

Why a restart cannot mail anybody twice

Every recipient is claimed immediately before the message is handed over, with a write that only succeeds while that address is still waiting. A worker killed by a deploy or by running out of memory is restarted onto the same batch, and every address it already sent to is no longer waiting, so it skips them.

The same trick guards the issue itself. Pressing send twice, or the scheduler reaching an issue in the same second somebody presses the button, resolves to one claim on the issue and one snapshot of the list; the second attempt is told the issue is already sending rather than starting a parallel send over the same addresses.

There is a cost to doing it in that order, and Issue Mint reports it rather than hiding it. A worker killed in the gap between claiming an address and the provider answering leaves one message nobody can be sure about. That address is not retried, because retrying it might mail somebody twice, and it is counted separately from delivered on the report, with a sentence saying that the send was interrupted at that point.

How a send closes out

When every batch has run, whether the send was clean or partly broken, Issue Mint writes the outcome from the recipient rows rather than from what the queue thought happened.

Your recipient count is set to the addresses actually taken on, delivery figures are recomputed from the same place the provider’s own events write them, and an email comes to you with the numbers in it. If more than 5 per cent of addresses failed, that email also names the reason the provider gave most often, because “your list needs work” and “your address is not verified” call for completely different actions. Addresses never attempted and addresses that could not be confirmed are named separately rather than folded into the total.

The fuller picture arrives a day later, once opens and clicks have settled, as the issue report. The issue’s social card is generated at the same time, so the first person to share the link gets a proper preview.