Design and Implementation of a Scalable Java Payment System Using RabbitMQ, Redis, MongoDB, and MySQL

The author, a Java Web full‑stack engineer, introduces a narrowly scoped payment system that provides channel management, gateway integration, basic payment/refund/transfer capabilities, record keeping, and monitoring, while leaving accounting and risk control to a separate financial system.

Payment initiation is modeled as an asynchronous workflow using Java 8's ExecutorService and CompletableFuture, with tasks queued in RabbitMQ, cached in Redis, and persisted in MongoDB. The article enumerates twelve sequential steps from task submission to the final response returned to the client.

Three class diagrams are described: (1) PayTask and Payment as MongoDB documents cached in Redis during execution; (2) a TaskRunner hierarchy that consumes tasks from RabbitMQ, implements run(task) and retry(task), and supports configurable retry attempts (default three, maximum five); (3) PayChannel and PayParams that encapsulate channel‑specific configuration, signatures, and credentials.

The MongoDB document structure for a payment is presented in full JSON form, wrapped in ... tags, highlighting fields such as payId, appId, amount, metadata, and the nested credential object.

The author explains the choice of MongoDB over relational databases, citing team stack compatibility, widespread adoption, and the need for flexible, dynamically extensible document schemas.

MySQL is used for static configuration tables (e.g., pay_channel, app_settings, app_channel, alipay_settings, wx_settings), each illustrated with an ER‑style image reference.

Refund processing mirrors the payment flow: a client supplies the payId, a RefundTask is queued, executed, and a Refund document is stored in MongoDB. The article includes the JSON schema for a refund document, again wrapped in ... tags.

Callback handling is event‑driven: third‑party gateways post webhook notifications, which are parsed per channel, persisted as Event documents in MongoDB, and turned into EventTask objects for downstream consumption. The Event JSON example is provided.

In conclusion, the author acknowledges that the implementation resembles a payment‑gateway layer rather than a full financial system, but emphasizes its practical, code‑centric approach and plans for future enhancements.