> ## Documentation Index > Fetch the complete documentation index at: https://help.dingtalk.io/llms.txt > Use this file to discover all available pages before exploring further. # RDS Push Overview > DingTalk pushes subscribed callback events to your app, such as Contacts changes and App authorization changes. Developers can synchronize data in real time to better integrate their business systems. ## What Is RDS Push RDS push is an upgraded version that replaces HTTP protocol push. It is a push solution independently developed by the DingTalk Open Platform in combination with Alibaba Cloud. While ensuring data security, RDS push greatly simplifies the push protocol, reduces the number of data transfers, increases data transfer speed, and improves push stability. RDS push supports data transfer not only between DingTalk and ISVs, but also between DingTalk and enterprise developers. It supports both local development and debugging as well as online deployment and operations, greatly simplifying the process for ISVs and organizations to integrate with DingTalk. ## Capability Comparison Between RDS Push and HTTP Push | **RDS Push** | **HTTP Push** | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Supports the synchronization protocol, ensuring that data is reliably written to the developer's RDS. If the developer's RDS fails, the data is permanently stored in DingTalk. | Does not support the synchronization protocol. Data loss may occur when the network is abnormal or the developer's service fails. | | Pushes the final state of the business data, so developers can use the data pushed by DingTalk Cloud directly. This also reduces the number of calls developers make to the DingTalk Open Platform, avoiding throttling limits. | Pushes the business ID. After receiving the push, developers still need to call DingTalk Open Platform APIs to query the final state of the data, which is prone to throttling limits. | | Pushes data at different rates based on the RDS specifications and capabilities of the developer receiving the push. | Push can create instantaneous peaks in HTTP requests, which may increase the load on the developer's server and cause it to crash. | | The pushed data is in plaintext, requiring no signature verification or encryption/decryption logic. | The pushed data is in ciphertext, requiring developers to verify signatures and perform encryption/decryption on their own, and to implement signature verification and encryption/decryption logic in different programming languages. | | The data channel is an internal network channel with no traffic costs, high security level, and high efficiency. | The data channel is a public network channel with traffic costs, a low security level, and low efficiency. | ## Process Comparison Between RDS Push and HTTP Push | **Development Stage** | **RDS Push** | **HTTP Push** | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Create an app/suite | Developers need to set up an RDS instance for receiving pushes (during the development stage, any MySQL instance with a public IP can be used). | Developers need to prepare a program with a public address to verify pushes. (For official launch, the program must be deployed on DingTalk Cloud.) | | Organization authorizes and activates the app/suite | Developers need to implement functionality that polls and reads the pushed database table to obtain the authorization information of the organizations that have activated the app. **The process is short and issues are easy to troubleshoot.** | Developers need to implement the following four functions: 1) Receive the temporary authorization code push, 2) Exchange the temporary authorization code for a permanent authorization code, 3) Activate the app, and 4) Obtain the authorization information of the organizations that have activated the app. The process is long and issues are hard to troubleshoot. | | Monitor real-time data changes of organizations | Developers need to select the data to monitor on the app/suite details page, then poll and read the database table that receives the pushes. **A single action, simple to perform.** | Developers need to register a monitoring address for each organization. After receiving a push, they must query the DingTalk Open Platform again to obtain the final data. This requires multiple API calls and makes API debugging complex. |