Need push notifications with retries and dead token cleanup

A solid way to handle push notifications with retries and dead-token cleanup is to build the system around a few clear rules:

Core flow

1. Send notification
2. If transient failure occurs, retry with backoff
3. If token is permanently invalid, mark it dead and stop using it
4. Periodically clean up dead tokens from your DB

---

Recommended delivery model

1) Store device tokens

Have a table/collection like:

• user_id
• device_token
• platform (ios, android, etc.)
• status (active, dead)
• last_seen_at
• last_failed_at
• failure_count

---

2) Classify push errors

When calling your push provider (FCM, APNs, OneSignal, etc.), distinguish:

Retryable errors

Retry these with exponential backoff:

• network timeout
• 5xx provider errors
• rate limiting / 429
• temporary unavailable errors

Non-retryable / dead token errors

Immediately mark token as dead:

• invalid token
• unregistered token
• expired token
• not registered
• bad device token format

For example, with Firebase Cloud Messaging, errors like:

• UNREGISTERED
• INVALID_ARGUMENT (if clearly token-related)

should usually mean the token is dead.

---

Retry strategy

Use:

• exponential backoff
• max retry count (e.g. 3–5 attempts)
• jitter to avoid retry storms

Example schedule:

• attempt 1: immediate
• attempt 2: after 1 min
• attempt 3: after 5 min
• attempt 4: after 15 min

If all retries fail, move the notification job to a dead-letter queue or mark it failed.

---

Dead token cleanup

When you get a permanent token error:

1. Set token status to dead
2. Store reason + timestamp
3. Stop sending to it
4. Optionally remove it after a grace period

You can also run a cleanup job daily/weekly to:

• delete tokens marked dead for > 30 days
• remove tokens never used for a long time
• compact duplicate tokens

---

Best-practice architecture

Use a queue-based worker system:

• API server: accepts notification request
• Job queue: stores notification jobs
• Worker(s): send pushes, retry on transient errors
• Token service: updates token status based on provider response

This keeps sending reliable and prevents user requests from blocking.

---

Example logic

Pseudo-flow:

for token in user_tokens:
    if token.status == dead:
        skip

    try send push
    if success:
        record success
    if error is retryable:
        retry with backoff
    if error is permanent:
        mark token dead

---

Extra recommendations

• Deduplicate tokens per user/device
• Limit notifications per user to avoid spam
• Log provider response codes for analysis
• Track token churn by platform
• Batch sends when provider supports it
• Use idempotency keys for notification jobs

---

If you want, I can provide:

1. a database schema
2. a Node.js / Python / Go worker example
3. an implementation for FCM/APNs
4. a retry + dead-token cleanup design with Redis/Celery/BullMQ/SQS

If you tell me your stack, I’ll tailor it.