I'm unhappy with AWS SNS for reliable user notifications

If your main concern is reliability for user notifications, SNS can be a decent transport layer, but it’s often not enough by itself for a product-grade notification system.

A few common pain points with SNS:

• No strong delivery guarantees end-to-end
  SNS can retry, but once you add mobile push, email, SMS, or HTTP endpoints, reliability depends on each downstream channel too.

• Limited control over orchestration
  If you need fallback paths like “push → email → SMS,” deduplication, user preferences, quiet hours, retries, and audit logs, SNS alone gets clumsy.

• Harder to track delivery state
  You often need more visibility than SNS provides into “sent / delivered / failed / retried / acknowledged.”

• Operational complexity across channels
  Mixing SNS with Pinpoint, SES, Lambda, SQS, and app logic can become messy quickly.

What people usually do instead:

1. Use a durable notification service/queue as the source of truth

   • SQS, Kafka, or a database-backed outbox pattern
   • This ensures notification requests aren’t lost

2. Build a notification orchestration layer

   • Handles preferences, templates, retries, fallback channels, and idempotency

3. Use channel-specific providers

   • Email: SES, SendGrid, Postmark
   • SMS/voice: Twilio, Telnyx
   • Push: FCM/APNs directly or via a provider
   • In-app: WebSocket/polling + persisted inbox

4. Add observability

   • Track message lifecycle events
   • Store notification records per user and per channel

If you want to stay in AWS, a more reliable pattern is often:

• Application → Outbox table / SQS
• Worker/Lambda → Notification service
• SES / Pinpoint / FCM / APNs / SMS provider
• DynamoDB/RDS for status tracking

If you want, I can help you with one of these:

• a better AWS-native architecture
• a comparison of SNS vs Pinpoint vs SES vs SQS
• a design for reliable multi-channel notifications
• a migration plan away from SNS