How PalmPay Scaled African Payments with Alibaba Cloud RocketMQ

Background

PalmPay operates a mobile payment platform across several African countries. Rapid user growth created high‑volume, low‑latency transaction processing requirements.

Technical challenges

Transaction consistency : In a distributed architecture, a payment involves a database update and a notification message. If the database commit succeeds but the message fails, data becomes inconsistent. Traditional approaches require custom compensation logic.

High‑throughput message processing : Payment spikes overload the message middleware, increasing response latency and degrading user experience.

Elastic resource provisioning : Static capacity leads to idle resources during off‑peak periods and slow scaling during traffic bursts, threatening service stability.

Adopted solution – Alibaba Cloud RocketMQ

PalmPay integrated Alibaba Cloud RocketMQ (cloud‑native message queue) to address the three challenges. The integration follows a typical pattern: payment services produce messages to a RocketMQ topic; consumer services pull messages asynchronously for downstream processing.

Transactional messages

RocketMQ provides a half‑message and transaction check mechanism:

When a business transaction starts, the application sends a half‑message to RocketMQ. The message is stored but not visible to consumers.

The application executes the local database transaction.

If the local transaction commits, the application calls commitTransaction to make the half‑message visible. If the transaction rolls back, the application calls rollbackTransaction and the message is discarded.

If RocketMQ does not receive a commit/rollback response within a configurable timeout, it triggers a transaction check callback to the producer, which re‑evaluates the transaction status and decides whether to commit or discard the message.

This tightly couples message visibility with the outcome of the local transaction, guaranteeing that only successfully committed payments are propagated to downstream systems.

High‑concurrency handling

Payment requests are first enqueued in RocketMQ, which acts as a buffer that smooths traffic spikes (shaping). RocketMQ’s write path is optimized for low latency and can scale horizontally by adding broker nodes. Consumers can be deployed in a clustered or broadcast mode, allowing parallel processing of payment notifications. This architecture reduced average response time and enabled PalmPay to maintain a 99.99 % SLA during peak periods.

Elastic scaling with Serverless RocketMQ

RocketMQ Serverless (5.x) separates compute and storage, automatically adjusting resource allocation based on real‑time load:

During low traffic, idle broker instances are reclaimed, lowering operational cost.

When traffic surges, the service provisions additional compute capacity within seconds, ensuring stable throughput.

Built‑in monitoring, alerting, and message tracing simplify operations and reduce the need for manual capacity planning.

Billing is usage‑based, calculated from actual message volume, topic count, network traffic, and storage, which aligns cost with business demand.

Key outcomes

Strong data‑message consistency through transactional messaging.

Improved throughput and latency by decoupling payment ingestion from downstream processing.

Automatic, fine‑grained resource scaling that eliminates over‑provisioning and reduces operational overhead.

Conclusion

By adopting Alibaba Cloud RocketMQ and its Serverless 5.x edition, PalmPay built a highly available, low‑latency, and elastically scalable messaging backbone that supports high‑volume payment flows while preserving transactional integrity.