How do I build transactional notifications for order updates and password resets?

To build transactional notifications for things like order updates and password resets, think of them as event-driven, user-specific messages that must be delivered reliably and quickly.

1) Split transactional from marketing

Keep these separate from promotional email/SMS/push:

• Transactional: order confirmed, shipped, delivered, password reset, OTP, receipt
• Marketing: newsletters, offers, upsells

Why:

• different sending rules
• higher deliverability expectations
• different consent/compliance requirements

---

2) Use events as the trigger

Your app should emit events when something important happens.

Examples:

• order.created
• order.paid
• order.shipped
• order.delivered
• password_reset.requested
• password_reset.completed

A notification service listens for these events and sends the right message.

---

3) Create notification templates

Have templates per channel and per event.

Example templates:

• Email: “Your order #1234 has shipped”
• SMS: “Order #1234 shipped. Track: …”
• Push: “Your package is on the way”

For password reset:

• Email: reset link
• SMS: one-time code
• Push: security alert, if applicable

Use variables:

• {{customer_name}}
• {{order_id}}
• {{tracking_url}}
• {{reset_link}}
• {{expires_in_minutes}}

---

4) Prefer an async delivery pipeline

Don’t send notifications directly inside the request that updates the order or requests a reset.

Instead:

1. App writes the business change to DB
2. App publishes an event
3. Queue/worker picks it up
4. Notification service renders template
5. Provider sends message
6. Log result and retry if needed

This keeps your app fast and avoids lost messages if a request fails midway.

---

5) Make it reliable

Use:

• message queue: RabbitMQ, SQS, Kafka, Pub/Sub
• idempotency: avoid duplicate sends if the same event is processed twice
• retries with backoff
• dead-letter queue for failures
• audit logs for sent notifications

For example, if order.shipped is processed twice, use an idempotency key like:

• notification:order.shipped:order123:user456

---

6) Handle channel selection

Choose the right channel based on urgency and user preference.

Good defaults:

• Password reset: email + optional SMS OTP
• Order updates: email, SMS for major milestones, push if user enabled it

Rules might look like:

• shipped -> email + push
• delivered -> email
• password reset -> email only, or email + SMS if high-risk

---

7) Secure password reset flows

For password resets, use strong security practices:

• generate a single-use, time-limited token
• store only a hashed token server-side
• token expires in 10–30 minutes
• invalidate old tokens when a new one is generated
• don’t reveal whether an email exists (“If an account exists, we sent instructions”)
• log reset requests and completions
• optionally notify user on successful password change

---

8) Design order notifications carefully

For order updates:

• trigger based on real business state changes
• include order ID, status, tracking info
• avoid sending too many messages
• group updates when possible
• localize time, language, and currency

Example lifecycle:

• order placed
• payment confirmed
• packed
• shipped
• out for delivery
• delivered
• delayed/cancelled

---

9) Add observability

Track:

• sent
• delivered
• bounced
• failed
• retried
• opened/clicked if applicable

This helps you catch:

• provider outages
• template bugs
• bad data
• delivery issues

---

10) A simple architecture

A common setup:

• Core app: updates orders, auth, accounts
• Event bus / queue: carries notification events
• Notification service: decides channel + template
• Provider integrations: SendGrid, SES, Twilio, Firebase, etc.
• DB: stores notification logs and preferences

---

Example flow: password reset

1. User submits email
2. Auth service creates reset token
3. Save hashed token with expiry
4. Publish password_reset.requested
5. Notification worker sends email with reset link
6. User clicks link
7. Token validated and password changed
8. Publish password_reset.completed
9. Send confirmation email

---

Example flow: order shipped

1. Shipping system marks order as shipped
2. Emit order.shipped
3. Notification worker loads customer preferences
4. Render email/SMS template with tracking URL
5. Send message
6. Record status in notification log

---

Recommended minimum features

If you’re starting out, implement:

• event-based triggers
• email templates
• a queue/worker
• retry logic
• notification logs
• tokenized password reset flow
• user notification preferences

---

If you want, I can also provide:

1. a database schema for notifications and reset tokens,
2. a sample implementation in Node.js / Python / Java, or
3. a reference architecture diagram.