ApsaraMQ for RocketMQ provides asynchronous communication, transactional consistency, ordered delivery, traffic buffering, and real-time data synchronization for distributed systems.
For example, an e-commerce enterprise covers business aspects such as registration, ordering, inventory, and logistics. The enterprise must handle business peaks during promotional events such as flash sales, anniversary celebrations, and regular special offers. These activities impose significant challenges on distributed microservice architectures.
The following scenarios show how ApsaraMQ for RocketMQ solves common architectural challenges. Each scenario uses an e-commerce platform as the running example.
| Scenario | What it solves |
|---|---|
| Asynchronous decoupling | Reduce response latency by offloading secondary tasks |
| Distributed transaction consistency | Keep data consistent across independent services |
| Ordered message delivery | Process messages in strict FIFO order per entity |
| Peak-load shifting | Absorb traffic spikes without overwhelming downstream services |
| Large-scale cache synchronization | Broadcast real-time updates to every server in a cluster |
Asynchronous decoupling
When a user registers on an e-commerce platform, the system sends both an email and an SMS confirmation. The registration service, the email service, and the SMS service are independent components. How they interact determines how long the user waits.
Without a message queue
Serial processing chains each step sequentially. If each step takes 50 ms, the user waits 150 ms before seeing a success response.
The user submits registration credentials, and the registration service writes the account data.
The registration service calls the email service to send a confirmation email.
The email service calls the SMS service to send a confirmation message.
The user receives a success response after all three steps complete.
Parallel processing sends the email and SMS notifications at the same time, reducing the total wait to 100 ms.
The user submits registration credentials, and the registration service writes the account data.
The registration service calls the email service and the SMS service simultaneously.
After both notifications are sent, the user receives a success response.
Both approaches tightly couple the registration service to the notification services. If either notification service slows down or becomes unavailable, the registration is delayed or fails.
With ApsaraMQ for RocketMQ
Place ApsaraMQ for RocketMQ between the registration service and the notification services. The registration service publishes a single message and returns immediately, cutting the user's wait to approximately 55 ms.
The user submits registration credentials, and the registration service writes the account data.
The registration service publishes a registration-success message to ApsaraMQ for RocketMQ and returns a success response immediately.
The email service and SMS service each subscribe to the registration topic and send notifications asynchronously.
The registration service no longer depends on the availability or performance of downstream notification services. Producers and consumers evolve independently as long as the message format stays the same.
Asynchronous decoupling suits any operation that does not require an immediate response.
Distributed transaction consistency
In the registration example above, the registration service and the email service are separate systems. Their data must stay consistent: a successful registration must trigger an email, and a failed registration must not.
The problem with normal messages
With standard (non-transactional) messages, the registration service writes data first, then publishes a success message. If the publish fails, the email service never receives the message, and the two systems fall out of sync.
The registration service processes the registration.
The registration service publishes a success message to ApsaraMQ for RocketMQ.
If the publish succeeds, the email service receives the message (step 3).
If the publish fails, the email service never learns about the registration. The registration data and the email data are now inconsistent.
The email service receives the success message.
The email service sends a confirmation email.
Transactional messages solve this
Transactional messages in ApsaraMQ for RocketMQ use a two-phase protocol. A half message is sent first, then committed or rolled back based on the local transaction outcome.
The registration service sends a half message to ApsaraMQ for RocketMQ.
If the half message is sent successfully, proceed to step 2.
If it fails, the registration does not proceed. Both systems remain consistent.
The registration service runs the local registration transaction.
If registration succeeds, proceed to step 3a.
If registration fails, proceed to step 3b.
The registration service reports the transaction outcome:
3a. Commit: ApsaraMQ for RocketMQ delivers the message to downstream consumers. Proceed to step 4.
3b. Rollback: ApsaraMQ for RocketMQ discards the half message. No notification is sent. Both systems remain consistent.
The email service receives the registration-success message.
The email service sends a confirmation email. Both systems are now consistent.
At every decision point, data across both services stays in sync. For implementation details, see Transactional messages.
Ordered message delivery
Some operations must be processed in a specific sequence. If a user's registration record is created, updated, and then deleted, these events must reach consumers in exactly that order. Out-of-order processing could leave stale or inconsistent data.
ApsaraMQ for RocketMQ supports partitionally ordered messages. Messages within a topic are partitioned by sharding key, and all messages that share the same sharding key are delivered and consumed in strict first-in, first-out (FIFO) order within their partition. This ensures that each message is consumed by one process.
Applied to user registration: Set the user ID as the sharding key. All events for the same user -- create, update, delete -- land in the same partition and are processed in publish order.
FIFO ordering is guaranteed within a single partition. Messages across different partitions have no ordering guarantee.
For implementation details, see Ordered messages.
Peak-load shifting
During flash sales or group-buying events, traffic sharply increases due to large numbers of user requests. Downstream notification services may be unable to handle the sudden surge, which leads to dropped messages or outages.
ApsaraMQ for RocketMQ buffers messages between the high-throughput application tier and capacity-limited downstream services.
Users submit a large volume of purchase requests to the flash sales processing system.
The flash sales system validates requests against business rules and publishes qualifying orders to ApsaraMQ for RocketMQ.
The notification system consumes messages at a sustainable rate and sends purchase-success notifications.
Users receive confirmation notifications.
The queue absorbs the traffic burst, letting the notification system process messages at its own pace.
Large-scale cache synchronization
During large-scale shopping events like Double 11, each venue has a wide variety of items whose prices change frequently. Traditional per-request cache lookups overload cache servers. The network interface controllers (NICs) become saturated, and page load times increase.
ApsaraMQ for RocketMQ addresses this with broadcasting consumption. In clustering consumption (the default), each message is delivered to only one consumer in a consumer cluster. In broadcasting consumption mode, every consumer in the cluster receives every message.
Applied to price synchronization: When a price changes, a single message is published to ApsaraMQ for RocketMQ. Every application server in the consumer cluster receives the update and refreshes its local cache. This eliminates repeated cache queries and keeps all servers in sync.
For details on consumption modes, see Clustering consumption and broadcasting consumption.