How Modern Backends Actually Send Verification Emails (Queues, Workers, JWTs)

Описание: You click Register, and a second later you see check your email. That message feels instant, but the email behind it is never sent directly inside that request. This video walks through the real pipeline modern backends use to send and verify a signup confirmation email, and why it's built the way it is.

The golden rule first: emails are always sent asynchronously. If the API called a third-party email provider directly inside the registration request, a slow network or a provider outage would slow down or break account creation itself. So instead, the API validates the input, hashes the password, and creates the user record in one atomic database transaction, then publishes an event onto a message broker like RabbitMQ, Kafka, or AWS SQS, and immediately returns a success response to the browser. A separate background worker picks up that event, renders the email template with the user's details, and calls a transactional email provider such as SendGrid, Postmark, AWS SES, or Resend over a normal HTTP request. Almost nobody runs their own SMTP server anymore, because managing deliverability, IP reputation, and SPF, DKIM, and DMARC records is its own full time job. Once the provider sends the email, it reports back through webhooks, so bounces, spam complaints, and opens all flow back into your database automatically.

Then the video covers the production tech stack behind all of this, the message broker, the worker engine, the templating engine, the email provider, and a dead letter queue for jobs that keep failing, along with three patterns that keep the whole thing reliable in practice: the transactional outbox pattern, idempotent message handling, and exponential backoff retries.

The second half zooms in on the token that actually rides inside that email. Modern backends favor stateless, cryptographically signed tokens, JWTs or HMAC tokens, over database-backed ones, with a short expiration window, a scoped purpose so a verification token can't be replayed as a password reset, and a single use guarantee enforced through a short-lived Redis entry. You'll see exactly what happens after someone clicks Verify Email: the link opens a frontend page first rather than an API endpoint directly, since email security scanners will pre fetch and burn a link that mutates state on a plain page load. That frontend page then fires a POST request carrying the token to the backend, which runs it through a signature check, an expiration check, a purpose check, and a replay check before marking the account verified, logging the user in automatically, and redirecting them straight to onboarding.

Topic: Backend Architecture