Transactional Triggered Email Architecture: Implementation Guide

Why Architecture Matters for Transactional Email

Transactional email has different requirements than marketing email: it must arrive fast, it must arrive reliably, and a failure means a user can't reset their password or confirm their order.

Getting the architecture right means separating concerns, building in redundancy, and isolating transactional reputation from marketing reputation.

The Four-Layer Architecture

Layer 1: Event Source

Your application emits events when user actions require email:

• User signs up → user.created event
• User requests password reset → password.reset_requested event
• Order placed → order.confirmed event
• Payment failed → payment.failed event

Events should be lightweight: event type, user ID, timestamp, and minimal context. Don't build the email in your application layer.

Layer 2: Message Queue

A queue sits between your application and the email service:

• Buffers events during traffic spikes
• Retries failed deliveries automatically
• Prevents your application from blocking on email sends
• Provides a record of every email event

Options: Redis Queue, AWS SQS, RabbitMQ, or a managed queue service. For most applications, a simple Redis-backed queue is sufficient.

Layer 3: Email Service (Worker)

A background worker processes the queue:

1. Reads event from queue
2. Looks up recipient data
3. Selects and renders the email template
4. Calls the delivery provider API
5. Logs the result
6. On failure: returns event to queue with retry metadata

This layer handles template rendering, personalization, and provider API calls. Keep it stateless — any worker instance should be able to process any event.

Layer 4: Delivery Provider

The provider handles actual SMTP delivery:

• Postmark — fastest delivery, best for critical transactional
• AWS SES — cheapest at scale
• SendGrid — most flexible, good API
• Resend — best developer experience

Separation From Marketing

This is the most important architectural decision: keep transactional and marketing email on completely separate infrastructure.

Component	Transactional	Marketing
Subdomain	mail.yourdomain.com	marketing.yourdomain.com
Provider	Postmark or SES	SendGrid, Klaviyo, etc.
IP	Dedicated or provider shared pool	Separate IP/pool
SPF/DKIM	Separate keys	Separate keys
DMARC	Same domain policy	Same domain policy
Reputation	Isolated	Isolated

If your marketing sends generate complaints and your reputation drops, your transactional email is unaffected. Users can still reset passwords and receive order confirmations.

Practitioner note: I've seen ecommerce businesses lose transactional delivery because they ran everything through one ESP. A bad marketing campaign tanked their sender reputation, and suddenly order confirmations were hitting spam. Separation isn't optional — it's insurance.

Failover Design

Primary + Fallback Provider

Configure two providers: primary (Postmark) and fallback (SES). If the primary API returns an error or times out:

1. Worker retries primary once
2. On second failure, switches to fallback provider
3. Logs the failover event
4. Alerts ops team
5. Continues using fallback until primary is confirmed healthy

This prevents a single provider outage from blocking all transactional email.

Retry Strategy

Use exponential backoff for retries:

• Attempt 1: Immediate
• Attempt 2: 30 seconds
• Attempt 3: 2 minutes
• Attempt 4: 10 minutes
• Attempt 5: 1 hour
• After 5 failures: Log, alert, move to dead letter queue

Don't retry indefinitely. A password reset email that arrives 6 hours late is useless.

Template Management

Keep Templates in Code

Store email templates in your codebase, not in the ESP dashboard. This gives you:

• Version control
• Code review for template changes
• Consistent rendering across providers (failover works)
• Testing in CI/CD pipeline

Rendering

Use a template engine (Handlebars, Mjml, React Email) to render HTML from templates + data. Render on the worker layer, then pass rendered HTML to the provider API.

For HTML email best practices, keep templates simple, inline CSS, and test across email clients.

Practitioner note: Provider-specific templates create vendor lock-in and make failover impossible. If your templates live in Postmark and Postmark goes down, your fallback provider can't render them. Render locally, send rendered HTML to any provider.

Monitoring Transactional Email

Key Metrics

• Delivery latency: Time from event to inbox (target: <10 seconds)
• Delivery rate: Percentage successfully delivered (target: >99.5%)
• Bounce rate: Hard bounces indicate bad addresses (target: <0.5%)
• Queue depth: How many events are waiting (target: near 0 during normal operation)
• Failover events: How often the fallback provider is used

Alerting

Set up alerts for:

• Queue depth exceeds 100 (processing bottleneck)
• Delivery rate drops below 99% (provider issue)
• Failover activates (primary provider problem)
• Hard bounce rate exceeds 1% (list quality issue)

Common Mistakes

1. Sending transactional through your marketing ESP. Klaviyo, Mailchimp, and ActiveCampaign are not transactional email providers. Use a dedicated service.

2. Synchronous sending. Don't call the email API in your request handler. Use a queue. Synchronous sends add latency to your API responses and fail silently if the provider is slow.

3. No retry logic. APIs fail. Networks hiccup. Without retries, transactional emails get lost silently.

4. Sharing domains. Transactional and marketing on the same subdomain means shared reputation. One bad campaign affects password reset delivery.

Practitioner note: The cost of proper transactional architecture is minimal — a Redis instance and a few hundred lines of worker code. The cost of not having it is customers who can't log in, orders without confirmations, and support tickets that could have been prevented.

If you're building transactional email infrastructure and need architecture review, schedule a consultation.

Sources

• Postmark: Transactional Email Best Practices
• AWS: SES Developer Guide
• SendGrid: Transactional Email Guide
• M3AAWG: Best Practices for Transactional Messages
• Resend: Documentation

---

v1.0 · April 2026