In the fields of e-commerce and new retail, benefit issuance is applicable to scenarios where specific operational activities are carried out for specific users. Technically, it is difficult to ensure strong consistency between databases and cached data in these scenarios. To solve this problem, Alibaba Cloud ApsaraMQ for RocketMQ provides benefit issuance. This topic uses an e-commerce scenario as an example to illustrate the background, architecture, and benefits of the benefit issuance solution.


When an e-commerce platform decides to carry out marketing activities for specific users, it sets different marketing policies based on different user groups, which may involve but are not limited to:
  • User screening: sets specific criteria for issuing benefits to different users, such as new users and members, based on business requirements.
  • Benefit types: include red envelopes, points, and coupons.
  • Collection cost: sets the cost of collecting benefits, for example, consuming member points to collect discount coupons.
  • Time control: sets the timing of benefit issuance, for example, issuing 100 coupons to new users at 10:00 a.m.
  • Inventory: determines whether the number of benefits is sufficient, and whether it matches the number of target users.

The operation data is written into a database and then converted into technical policies, which are further written into the cache and converted into user issuance link data, that is, rules. Only users who meet these rules are allowed to collect the corresponding benefits.


Users can collect benefits by accessing corresponding cached data. This ensures efficient user access and reduces the pressure on databases. However, this leads to new problems:

  • Excessive rules result in excessive database data to be written to the cache, and further result in great pressure on the downstream cache. However, such cases are rare.
  • Database data is written to the cache only once. Therefore, if data writing fails due to network jitter or other reasons, the data update is delayed. For example, assume the inventory originally needs to be set to 100,000 benefits, but the operation policies change the number to 10. If the data is not synchronized in time, the downstream cannot be notified, resulting in capital loss.


ApsaraMQ for RocketMQ provides a retry mechanism and prevents messages from being lost. Therefore, the benefit issuance solution can ensure strong consistency between databases and cached data. Specifically, ApsaraMQ for RocketMQ is used between databases and the cache. The following figure shows the architecture.



ApsaraMQ for RocketMQ provides the following advantages:

  • It supports extremely high data throughput.
  • It supports the accumulation of large message volumes, mitigating the impact of traffic peaks on downstream applications.
  • It simplifies the implementation between databases and the cache, greatly reducing the code development workload. Without ApsaraMQ for RocketMQ, the implementation would be very complicated.
  • It allows users to send and subscribe to messages in real time and provides the retry feature, which prevents messages from being lost and ensures strong message consistency.

More information

For more information about the features of ApsaraMQ for RocketMQ, see Message retry.