Design and Implementation of a General‑Purpose Asynchronous Processing SDK for Backend Systems

In the introduction, the author emphasizes the need for a system design that follows the open‑closed principle while handling increasing business complexity, and proposes a generic asynchronous processing SDK to simplify implementation.

The purpose section states that asynchronous processing guarantees method execution without blocking the main flow and ensures data is not lost, achieving eventual consistency.

Advantages include a non‑intrusive design with independent database, scheduled tasks, message queue, and UI; use of Spring transaction event mechanisms to prevent business impact even if async parsing fails; and automatic handling of methods running within transactions.

Principle : After bean initialization, the container scans all methods for the @AsyncExec annotation and caches them. At runtime, an AOP aspect publishes an event, and a transactional event listener processes the asynchronous execution strategy.

Key configuration example:

@TransactionalEventListener(fallbackExecution = true, phase = TransactionPhase.AFTER_COMPLETION)

fallbackExecution=true – process the event even when no transaction is active.

TransactionPhase.AFTER_COMPLETION – handle the event after transaction commit or rollback.

Components used by the SDK:

Kafka message queue

XXL‑Job scheduled tasks

MySQL database

Spring AOP

Vue front‑end

Design patterns applied:

Strategy

Template Method

Dynamic Proxy

Several flowcharts (images) illustrate the processing pipeline, async strategy, security levels, execution states, and overall workflow.

Configuration (Apollo) example:

# Switch: disabled by default
async.enabled=true
# Application name
spring.application.name=xxx
# DataSource (Druid)
async.datasource.driver-class-name=com.mysql.jdbc.Driver
async.datasource.url=jdbc:mysql://127.0.0.1:3306/fc_async?useUnicode=true&characterEncoding=utf-8&zeroDateTimeBehavior=convertToNull&useSSL=false&allowMultiQueries=true&rewriteBatchedStatements=true
async.datasource.username=user
async.datasource.password=xxxx
async.datasource.filters=config
async.datasource.connectionProperties=config.decrypt=true;config.decrypt.key=yyy
# Static resources
spring.resources.add-mappings=true
spring.resources.static-locations=classpath:/static/
# Thread pool defaults
async.executor.thread.corePoolSize=10
async.executor.thread.maxPoolSize=50
async.executor.thread.queueCapacity=10000
async.executor.thread.keepAliveSeconds=600
# Delete record after success
async.exec.deleted=true
# Queue name prefix (default: application name)
async.topic=${spring.application.name}
# Retry settings
async.exec.count=5
async.retry.limit=100
async.comp.limit=100
# Login interception (default false)
async.login=false

Usage steps:

Enable async processing: scm.async.enabled=true

Add @AsyncExec(type = AsyncExecEnum.SAVE_ASYNC, remark = "Data Dictionary") to Spring‑proxied methods.

Access the manual handling UI at http://localhost:8004/async/index.html .

Notes :

Ensure the application name is set via spring.application.name .

Queue name defaults to ${async.topic:${spring.application.name}}_async_queue .

Business logic must be idempotent.

One queue per application; self‑consume and self‑produce.

Scheduled tasks: async retry every 2 minutes, async compensation every hour.

The article also shows screenshots of the UI and provides the GitHub repository link: https://github.com/xiongyanokok/fc-async .