A Lighter‑Than‑MQ Async Solution: Spring’s Hidden Transactional Event Feature

Why MQ May Be Overkill for Simple Asynchronous Needs

Developers often reach for RabbitMQ, RocketMQ, or Kafka to achieve business‑level async decoupling, peak‑shaving, and reliable local‑transaction async processing. For small projects, internal back‑ends, monoliths, or low‑traffic services, introducing a separate broker brings several drawbacks:

Additional deployment and maintenance of broker servers, consuming resources and requiring version upgrades.

Local development becomes cumbersome because the MQ must be started locally.

Another failure point: broker downtime blocks the async flow, forcing extra retry, dead‑letter, and monitoring logic.

For simple async scenarios the overhead is unnecessary and the learning curve is steep.

Spring’s Two Built‑In Lightweight Async Capabilities

Spring natively offers two zero‑dependency async mechanisms: @Async – memory‑based async execution managed by Spring’s thread pool. ApplicationEvent with TransactionalEventListener – an event‑driven approach that can be bound to the current database transaction. The hidden advanced feature is the ability to send the event only after the transaction commits and automatically discard it on rollback.

Three Async Solutions Compared

Below is a concise comparison of the three approaches:

RabbitMQ / Kafka

Dependency: Independent middleware, extra deployment.

Transaction consistency: Supports distributed and local transactional messages.

Persistence: Disk‑based, survives broker crash.

Clustering: Native multi‑instance distribution.

Suitable for: Cross‑service, high‑throughput, massive message volumes.

Ordinary @Async

Dependency: Only Spring, no third‑party.

Transaction consistency: Not supported – async task may run before transaction commit.

Persistence: In‑memory; messages are lost on service restart.

Clustering: Single‑instance only.

Suitable for: Non‑critical logs or simple background tasks without strict transactional guarantees.

Spring Transactional Event ( @TransactionalEventListener )

Dependency: Pure Spring, zero extra libraries.

Transaction consistency: Strongly bound – event fires only after successful commit, discarded on rollback.

Persistence: Can be extended with local DB or file storage as a fallback.

Clustering: Single‑instance by default; can be combined with DB persistence or MQ for multi‑instance sync.

Suitable for: Monolithic or mid‑size services needing reliable local async processing such as order notifications, inventory deduction, coupon issuance, or logging.

Core Conclusion

For internal monolithic scenarios that do not require cross‑service communication, Spring’s transactional event mechanism is essentially 100 % lighter than a traditional MQ solution, incurs zero operational cost, and eliminates the need for additional components.

Ordinary ApplicationEvent vs. Transactional Event

2.1 Problems with Regular ApplicationEvent

Publishing an event with applicationContext.publishEvent() executes the listener synchronously and immediately, or asynchronously via @Async, but it is not tied to the surrounding database transaction:

The async task may run before the transaction is committed.

If the transaction later rolls back, the async work has already been performed, leading to data inconsistency. Example: an order creation publishes a coupon‑grant event, the order transaction rolls back, yet the coupon is still issued, creating dirty data.

2.2 Transactional Event Core Capability (Spring Hidden Feature)

Spring provides the @TransactionalEventListener annotation with four execution phases, fully bound to the current transaction lifecycle: TransactionPhase.BEFORE_COMMIT: Executes before the transaction is committed. TransactionPhase.AFTER_COMMIT (most common): Executes only after the transaction successfully commits. TransactionPhase.AFTER_ROLLBACK: Executes when the transaction rolls back. TransactionPhase.AFTER_COMPLETION: Executes after the transaction ends, regardless of commit or rollback.

The underlying mechanism caches the event in a thread‑local buffer attached to the transaction. When the transaction commits, the buffered events are dispatched; if the transaction rolls back, the events are discarded, thereby guaranteeing transactional consistency.

Combined with @Async, this yields transaction‑guaranteed asynchronous execution , effectively replacing a local MQ for most monolithic use cases.

Code Demonstration

3.1 Basic Maven Dependencies

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-jdbc</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-aop</artifactId>
</dependency>

3.2 Enable Async Support

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.scheduling.annotation.EnableAsync;

@SpringBootApplication
@EnableAsync
public class AsyncEventApplication {
    public static void main(String[] args) {
        SpringApplication.run(AsyncEventApplication.class, args);
    }
}

3.3 Define Business Event (Order Creation Example)

import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.NoArgsConstructor;
import org.springframework.context.ApplicationEvent;
import java.math.BigDecimal;

@Data
@NoArgsConstructor
@AllArgsConstructor
public class OrderCreateEvent extends ApplicationEvent {
    private String orderNo; // order number
    private Long userId;    // user ID
    private BigDecimal amount; // order amount

    public OrderCreateEvent(Object source, String orderNo, Long userId, BigDecimal amount) {
        super(source);
        this.orderNo = orderNo;
        this.userId = userId;
        this.amount = amount;
    }
}

3.4 Publish Event Within a Transactional Service

import lombok.RequiredArgsConstructor;
import org.springframework.context.ApplicationContext;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import java.math.BigDecimal;
import java.util.UUID;

@Service
@RequiredArgsConstructor
public class OrderService {
    private final ApplicationContext context;

    @Transactional(rollbackFor = Exception.class)
    public void createOrder(Long userId, BigDecimal amount) {
        // 1. Persist order record (omitted)
        String orderNo = "ORD" + UUID.randomUUID().toString().substring(0, 16);
        // 2. Publish transactional event – will be cached until commit
        context.publishEvent(new OrderCreateEvent(this, orderNo, userId, amount));
        // 3. Simulate exception to test rollback – the event will be discarded
        // int a = 1 / 0;
    }
}

3.5 Transactional Async Listener

import lombok.extern.slf4j.Slf4j;
import org.springframework.scheduling.annotation.Async;
import org.springframework.stereotype.Component;
import org.springframework.transaction.event.TransactionPhase;
import org.springframework.transaction.event.TransactionalEventListener;

@Slf4j
@Component
public class OrderEventListener {
    /**
     * After order commit, asynchronously issue coupon, push notification, and update sales stats.
     * AFTER_COMMIT guarantees execution only on successful commit; rollback discards the event.
     */
    @Async
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void handleOrderCreateEvent(OrderCreateEvent event) {
        log.info("Async event started, orderNo: {}", event.getOrderNo());
        sendCoupon(event.getUserId());
        sendUserNotice(event.getUserId(), event.getOrderNo());
        statOrderSales(event.getOrderNo(), event.getAmount());
        log.info("Order async event completed");
    }

    private void sendCoupon(Long userId) { /* coupon logic */ }
    private void sendUserNotice(Long userId, String orderNo) { /* notification logic */ }
    private void statOrderSales(String orderNo, BigDecimal amount) { /* stats logic */ }

    // Optional rollback listener
    @Async
    @TransactionalEventListener(phase = TransactionPhase.AFTER_ROLLBACK)
    public void handleOrderRollback(OrderCreateEvent event) {
        log.warn("Order transaction rolled back, async task discarded, orderNo: {}", event.getOrderNo());
    }
}

Production‑Grade Enhancements for the Native Event Mechanism

4.1 Custom Async Thread Pool to Avoid OOM

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.scheduling.annotation.EnableAsync;
import org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor;
import java.util.concurrent.Executor;
import java.util.concurrent.ThreadPoolExecutor;

@Configuration
@EnableAsync
public class AsyncThreadPoolConfig {
    @Bean("eventTaskExecutor")
    public Executor eventTaskExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(8);
        executor.setMaxPoolSize(32);
        executor.setQueueCapacity(200);
        executor.setThreadNamePrefix("event-async-thread-");
        executor.setRejectedExecutionHandler(new ThreadPoolExecutor.DiscardOldestPolicy());
        executor.initialize();
        return executor;
    }
}

Listeners can then specify the pool with @Async("eventTaskExecutor").

4.2 Failure Retry & Dead‑Letter Persistence

When a listener throws an exception, the event is lost. By adding an AOP around the listener method, the failed event can be serialized into a local event_dead_letter table and retried later by a scheduled job.

CREATE TABLE event_dead_letter (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    event_type VARCHAR(64) NOT NULL COMMENT 'event type',
    event_json TEXT NOT NULL COMMENT 'serialized event',
    retry_count INT DEFAULT 0 COMMENT 'retry attempts',
    max_retry INT DEFAULT 3 COMMENT 'max retries',
    create_time DATETIME DEFAULT NOW(),
    next_retry_time DATETIME DEFAULT NOW(),
    INDEX idx_next_retry(next_retry_time)
);

The retry job scans rows where retry_count < max_retry and republishes the event.

4.3 Cluster‑Wide Synchronization

Since the native in‑memory event is confined to a single JVM, multi‑instance scenarios can be handled in two ways:

Persist events to a shared database table and let each instance pull and process them (lightweight, no MQ).

For true cross‑service async, introduce an external MQ only for the distribution layer while keeping the local transactional event for intra‑service logic.

4.4 Idempotent Consumption via Redis

To avoid duplicate processing during retries, store a unique business identifier (e.g., order number) in Redis and check it before handling the event.

Why Ordinary @Async Is Not Recommended for Transactional Async

When @Async is used directly inside a @Transactional method, the async thread runs independently of the transaction. If the transaction later rolls back, the async work has already been performed, causing data inconsistency. The following example demonstrates the issue:

@Service
@RequiredArgsConstructor
public class WrongOrderService {
    private final AsyncTaskService asyncTaskService;

    @Transactional(rollbackFor = Exception.class)
    public void createOrder(Long userId) {
        // 1. Insert order record
        // 2. Call async method directly
        asyncTaskService.sendCoupon(userId);
        // Simulate exception to trigger rollback
        int i = 1 / 0;
    }
}

@Service
public class AsyncTaskService {
    @Async
    public void sendCoupon(Long userId) {
        // Coupon is sent even though the surrounding transaction rolls back
    }
}

The root cause is that @Async executes in a separate thread that does not wait for the transaction to commit. By contrast, @TransactionalEventListener is managed by Spring’s transaction manager, ensuring the event is only processed after a successful commit, thereby completely avoiding this problem.

Full Summary

Most developers only know about Spring’s @Async for asynchronous work, overlooking the powerful @TransactionalEventListener that provides transaction‑bound async execution without any external broker. This zero‑deployment, zero‑maintenance approach guarantees that asynchronous tasks run only when the transaction succeeds and are automatically discarded on rollback. Compared with heavyweight MQ solutions, it is simpler, cheaper, and sufficient for monolithic or mid‑size services. When high‑throughput, cross‑service distribution is required, MQ can still be introduced alongside the local event mechanism. Custom thread pools, dead‑letter persistence, retry scheduling, and Redis‑based deduplication complete the production‑grade toolkit.