I'm building a startup and need a simple push notification infrastructure

Here’s a simple, startup-friendly push notification infrastructure you can build without overengineering it.

1) Core idea

Use a small backend service that:

1. stores user/device push tokens
2. accepts notification requests from your app/backend
3. queues jobs
4. sends to APNs (iOS) and FCM (Android/Web)
5. tracks delivery/invalid tokens

2) Basic architecture

Components

• Client apps

  • iOS app registers with APNs
  • Android app registers with FCM
  • Web app can use FCM Web Push
  • app sends device token + user ID to your backend

• API backend

  • endpoints to register/unregister tokens
  • endpoint to create notification requests
  • auth, rate limiting, validation

• Database

  • users
  • devices
  • notification requests
  • delivery logs

• Job queue

  • Redis + BullMQ / Sidekiq / Celery / SQS
  • async sending so your API stays fast

• Notification worker

  • pulls jobs from queue
  • sends to APNs/FCM
  • retries transient failures
  • marks bad tokens inactive

• Provider services

  • Apple Push Notification service (APNs)
  • Firebase Cloud Messaging (FCM)

3) Minimal data model

devices

• id
• user_id
• platform (ios, android, web)
• push_token
• enabled
• last_seen_at
• created_at, updated_at

notification_requests

• id
• type
• title
• body
• data JSON
• target_user_id or segment fields
• status (queued, sent, failed)
• created_at

notification_deliveries

• id
• notification_request_id
• device_id
• provider
• provider_message_id
• status
• error_code
• created_at

4) Main flow

Device registration

1. app gets push token from APNs/FCM
2. app calls backend: POST /devices
3. backend stores token and device metadata

Send notification

1. backend creates a notification request
2. enqueues a job with target users/devices
3. worker resolves device tokens
4. worker sends via APNs/FCM
5. worker stores success/failure and disables invalid tokens

5) Suggested MVP tech stack

Keep it boring and cheap:

• Backend: Node.js (NestJS/Express) or Python (FastAPI/Django)
• Queue: Redis + BullMQ (Node) or Celery (Python)
• DB: Postgres
• Push providers: APNs + FCM
• Hosting: Render/Fly.io/AWS ECS/Lambda
• Monitoring: Sentry + basic logs + metrics

6) API endpoints

Register token

POST /devices

{
  "user_id": "123",
  "platform": "ios",
  "push_token": "abc123",
  "app_version": "1.0.0"
}

Remove token

DELETE /devices/:id

Send notification

POST /notifications

{
  "target_user_ids": ["123", "456"],
  "title": "Welcome",
  "body": "Thanks for signing up!",
  "data": {
    "screen": "home"
  }
}

7) Important operational details

• Deduplicate tokens: same token may re-register
• Handle token rotation: devices change tokens over time
• Disable invalid tokens after APNs/FCM rejection
• Retry transient failures with exponential backoff
• Batch sends when possible
• Log provider errors for debugging
• Keep payloads small
• Respect user preferences and opt-outs

8) Multi-tenant / segmentation later

If you need segments later, add:

• tags
• locale
• timezone
• last_active_at
• subscription preferences

Then you can support:

• all users
• active users
• paid users
• users in a region
• event-triggered messages

9) If you want the simplest possible version

You can even start with:

• a single table of devices
• a send_notification() endpoint
• one worker process
• direct APNs/FCM sending
• no fancy segmentation or analytics

That’s enough for an MVP.

10) Build vs buy

If you want to move fast, consider:

• OneSignal
• Braze
• Firebase Cloud Messaging only for Android/Web
• AWS SNS for a more infra-heavy route

Build your own if you need:

• lower cost at scale
• custom workflows
• better control over user targeting
• fewer vendor dependencies

If you want, I can also give you:

1. a concrete database schema
2. a Node.js or Python implementation
3. a production-ready AWS architecture
4. a build-vs-buy recommendation for your startup stage