Distributed Transaction Solutions and Implementing Delayed Queues with RabbitMQ in Spring Boot

Distributed transactions become problematic in micro‑service architectures because a single business operation often spans multiple independent services.

The article lists common solutions: 2PC (two‑phase commit), TCC (try‑confirm‑cancel), maximum‑effort notification, and reliable messaging.

2PC is described with its two phases and a diagram.

TCC provides eventual consistency by defining Try, Confirm, Cancel methods, but incurs business logic coupling.

Maximum‑effort notification relies on retry mechanisms such as Alipay’s payment notifications, returning “success”.

Reliable messaging uses a message broker to store a message until the local transaction decides to commit or rollback.

Using RabbitMQ, the article shows how to achieve eventual consistency for order‑payment scenarios by employing a delayed queue.

Key concepts of delayed queues are dead‑letter messages and dead‑letter routing. When a message expires (TTL) or is rejected, it becomes a dead‑letter and can be routed to another queue.

Configuration code for Spring Boot creates the delayed queue, dead‑letter exchange, bindings, and sets TTL:

@Configuration
public class MyRabbitMQConfig {
    @Bean
    public Queue orderDelayQueue() {
        Map
arguments = new HashMap<>();
        arguments.put("x-dead-letter-exchange", "order.delay.exchange");
        arguments.put("x-dead-letter-routing-key", "order.release.order");
        arguments.put("x-message-ttl", 1000 * 10);
        return new Queue("order.delay.queue", true, false, false, arguments);
    }
    @Bean
    public Queue orderReleaseOrderQueue() {
        return new Queue("order.release.order.queue", true, false, false);
    }
    @Bean
    public Exchange orderDelayExchange() {
        return new TopicExchange("order.delay.exchange", true, false);
    }
    @Bean
    public Binding orderCreateOrderBinding() {
        return new Binding("order.delay.queue", Binding.DestinationType.QUEUE,
                "order.delay.exchange", "order.create.order", null);
    }
    @Bean
    public Binding orderReleaseOrderBinding() {
        return new Binding("order.release.order.queue", Binding.DestinationType.QUEUE,
                "order.delay.exchange", "order.release.order", null);
    }
}

A simple REST controller sends a test message to the delayed queue:

@RestController
public class TestController {
    @Autowired
    private RabbitTemplate rabbitTemplate;
    @GetMapping("/test")
    public String test() {
        rabbitTemplate.convertAndSend("order.delay.queue", "message");
        return "test";
    }
}

A listener consumes messages from the release queue after the TTL expires:

@RabbitListener(queues = "order.release.order.queue")
public void listener(Message message) {
    System.out.println("Received message: " + message);
}

When the /test endpoint is called, the message is held for the configured TTL (e.g., 10 seconds) and then routed to the release queue, where the listener processes it, demonstrating how delayed queues can enforce eventual data consistency.