I'm building a SaaS app and want transactional push notifications from backend events

A good way to think about this is: backend event happens → notification service decides if it should notify → push provider sends to device tokens.

For a SaaS app, a solid transactional push setup usually looks like this:

Recommended architecture

1. Your backend emits an event

   • Examples: invoice.paid, task.assigned, comment.created, build.failed
   • Do this via an internal event bus, message queue, or job system so notification delivery is asynchronous.

2. Notification service consumes the event

   • A dedicated notifications worker/service:
     • checks user preferences
     • applies templates
     • localizes content
     • resolves target devices
     • sends pushes

3. Store device tokens per user

   • Each device registers a push token.
   • Keep metadata:
     • user_id
     • platform (ios, android, web)
     • push token
     • last_seen
     • app version
     • locale/timezone
   • Remove invalid tokens when providers reject them.

4. Send via a push provider

   • Common options:
     • FCM for Android + web, and often as part of a broader setup
     • APNs for iOS
     • Or a wrapper service like OneSignal, Firebase, AWS SNS, Expo (if relevant)
   • For transactional notifications, direct integration with FCM/APNs gives more control.

5. Track delivery and failures

   • Log:
     • notification_id
     • event_type
     • user_id
     • device token
     • provider response
     • status (queued, sent, failed, invalidated)
   • Add retries with backoff for transient failures.

---

Important product rules

• Make notifications idempotent

  • Same backend event should not create duplicate pushes if retried.
  • Use an idempotency key like event_id + notification_type + user_id.

• Respect user preferences

  • Let users choose:
    • all transactional push on/off
    • per category settings
    • quiet hours, if appropriate

• Keep payloads small

  • Push payloads should be minimal and include only what the app needs.
  • Put full details behind an in-app fetch if needed.

• Use deep links

  • The notification should open the exact screen in your app.

• Don’t rely on push as the source of truth

  • Treat push as a delivery mechanism, not the actual data store.
  • The app should fetch current state from your backend after opening.

---

A simple event flow example

Example: invoice.paid

1. Billing service marks invoice as paid.
2. Backend publishes invoice.paid event.
3. Notifications worker receives the event.
4. Worker finds the right recipients.
5. Worker checks whether they have push enabled.
6. Worker creates a notification record.
7. Worker sends push via FCM/APNs.
8. App opens to the invoice details page.

---

Suggested data model

device_tokens

• id
• user_id
• platform
• token
• app_id
• locale
• timezone
• last_seen_at
• created_at
• updated_at
• revoked_at

notifications

• id
• event_id
• user_id
• type
• title
• body
• data_json
• status
• provider
• provider_message_id
• sent_at
• failed_at

---

If you want a fast implementation

If you’re trying to ship quickly, the shortest path is usually:

• backend events in a queue
• notifications worker
• OneSignal or Firebase
• device token registration endpoint
• notification preferences
• deep links
• logging + retries

---

Common pitfalls

• Sending push directly from request/response cycle
• No deduplication
• No invalid token cleanup
• No user preferences
• Too much data in payload
• No retry strategy
• No audit trail for what was sent

If you want, I can help you design:

1. a reference architecture
2. a database schema
3. an API design for device registration
4. or a sample implementation in Node.js, Python, or Go