How to Avoid Duplicate Push Notifications: In-Depth Analysis of CID Functionality

In push notification systems, duplicate push is a common issue, especially in scenarios with unstable networks or system retries. This article delves into the Client ID (CID) functionality, which helps you leverage this mechanism to effectively prevent duplicate message deliveries.

CID Functionality in Immediate Push Notifications

Core Features

CID is an optional parameter used to identify a specific push request. When a request is repeated with the same CID:

• The system returns the msg_id from the previous successful push
• Prevents messages from being pushed to users repeatedly
• Provides idempotency guarantees (the same operation has the same effect when executed multiple times)

Key Characteristics

Use Cases

1. Network Retries: Retry pushes with the same CID when the network is unstable
2. Idempotency Assurance: Ensure that the same message is not pushed repeatedly
3. Request Tracking: Track the status of specific pushes via CID

Request Examples

Single Push with CID

              
              curl --insecure -X POST -v https://pushapi-sgp.engagelab.com/v4/push \
  -H "Content-Type: application/json" \
  -u "AppKey:MasterSecret" \
  -d '{
    "options": {
      "cid": "order-notify-20230701-001",
      "time_to_live": 60
    }
  }'

            

Batch Push with CID

              
              curl --insecure -X POST -v https://pushapi-sgp.engagelab.com/v4/push/batch/regid \
  -H "Content-Type: application/json" \
  -u "AppKey:MasterSecret" \
  -d '{
    "requests": [
      {
        "options": {
          "cid": "user-12345-notification",
          "time_to_live": 60
        }
      }
    ]
  }'

            

Response Handling

Successful First Push

              
              {
  "msg_id": "2460001"
}

            

Repeated Push with Same CID

              
              {
  "msg_id": "2460001" // Returns the msg_id from the first push
}

            

Invalid CID Format

              
              {
  "error": {
    "code": 23003,
    "message": "CID format does not meet requirements"
  }
}

            

Error Code Description

Best Practices

1. Use CID for Critical Business: Apply CID to messages such as payment notifications and important alerts
2. Generate Meaningful Identifiers: Use formats like businessType-userID-timestamp (e.g., payment-12345-202307011030)
3. Network Retry Mechanism: Retry with the same CID when encountering network errors
4. Distinguish Identifiers in Batch Pushes: Use unique CIDs for each request in batch pushes for easier tracking
5. Client-Side CID Logging: Record CIDs on the client side for message deduplication and status queries

CID Functionality in Scheduled Tasks

Core Features

CID also applies to scheduled task creation, preventing duplicate creation of the same scheduled tasks:

• Reusing the same CID returns the previously created schedule_id
• Prevents the system from creating duplicate scheduled tasks

Key Characteristics

Request Example

              
              curl --insecure -X POST -v https://pushapi-sgp.engagelab.com/v4/schedules \
  -H "Content-Type: application/json" \
  -u "AppKey:MasterSecret" \
  -d '{
    "cid": "daily-reminder-202307",
    "trigger": {
      "daily": {
        "start": "2023-07-01",
        "time": "09:00:00"
      }
    }
  }'

            

Response Handling

Successful First Creation

              
              {
  "schedule_id": "0123456789"
}

            

Repeated Creation with Same CID

              
              {
  "schedule_id": "0123456789" // Returns the schedule_id from the first creation
}

            

Best Practices

1. Periodic Task Identification: Include cycle information in the CID (e.g., weekly-report-2023w27)
2. Task Parameter Summary: Include a hash of critical parameters (e.g., birthday-reminder-md5(params))
3. Distributed System Coordination: Use the same CID across multiple service instances to avoid duplicate creations
4. Task Update Mechanism: Use a new CID when modifying tasks

EngageLab Processing Flow

graph TD
    A[Receive Request] --> B{Contains CID?}
    B -->|Yes| C[Query Redis]
    B -->|No| D[Normal Processing]
    C --> E{CID Exists?}
    E -->|Yes| F[Return Stored msg_id/schedule_id]
    E -->|No| G[Process Request]
    G --> H[Store CID → ID Mapping]
    H --> I[Return New ID]

Frequently Asked Questions

Q: Why is the CID validity period 1 hour?
A: It is sufficient to cover typical retry scenarios while preventing unlimited storage growth. Critical businesses can extend the deduplication period using their own logs.

Q: Can the same CID be used with different appkeys?
A: Yes. CIDs only need to be unique under the same appkey.

Q: Does CID guarantee global uniqueness?
A: It only needs to be unique under the same appkey; the system does not require global uniqueness.

Q: How to validate the CID format?
A: Use the regular expression: /^[a-zA-Z0-9_-]{1,64}$/

Summary

By properly using the CID parameter, you can:

1. ✅ Prevent duplicate messages caused by network retries
2. ✅ Ensure idempotency for critical business messages
3. ✅ Simplify message tracking in distributed systems
4. ✅ Improve overall system reliability

Key Implementation Recommendations:

• Add CIDs to critical business messages
• Adopt the naming convention of business-entity-time
• Implement CID-based deduplication logic on the client side
• Monitor CID-related error codes

With the guidance in this article, you can effectively leverage CID functionality to build a more robust push notification system and completely resolve the issue of duplicate pushes.