Introduction

Spring AMQP is the Spring abstraction most commonly used with RabbitMQ to send and receive messages without writing low-level client code everywhere. A basic setup needs three things: broker infrastructure, a sender, and a listener. The harder part is not sending the first message. It is deciding how messages are routed, serialized, retried, and handled when consumers fail.

Define Queue, Exchange, and Binding Clearly

A lot of examples send directly to a queue, but explicit exchanges and bindings scale better because routing stays visible.

1import org.springframework.amqp.core.Binding;
2import org.springframework.amqp.core.BindingBuilder;
3import org.springframework.amqp.core.DirectExchange;
4import org.springframework.amqp.core.Queue;
5import org.springframework.context.annotation.Bean;
6import org.springframework.context.annotation.Configuration;
7
8@Configuration
9public class RabbitConfig {
10
11    public static final String QUEUE_NAME = "orders.queue";
12    public static final String EXCHANGE_NAME = "orders.exchange";
13    public static final String ROUTING_KEY = "orders.created";
14
15    @Bean
16    Queue ordersQueue() {
17        return new Queue(QUEUE_NAME, true);
18    }
19
20    @Bean
21    DirectExchange ordersExchange() {
22        return new DirectExchange(EXCHANGE_NAME);
23    }
24
25    @Bean
26    Binding ordersBinding(Queue ordersQueue, DirectExchange ordersExchange) {
27        return BindingBuilder.bind(ordersQueue)
28                .to(ordersExchange)
29                .with(ROUTING_KEY);
30    }
31}

This keeps queue names and routing keys explicit and avoids hidden broker assumptions.

Send Messages with RabbitTemplate

For sending, Spring AMQP uses RabbitTemplate.

1import java.math.BigDecimal;
2import org.springframework.amqp.rabbit.core.RabbitTemplate;
3import org.springframework.stereotype.Service;
4
5@Service
6public class OrderPublisher {
7
8    private final RabbitTemplate rabbitTemplate;
9
10    public OrderPublisher(RabbitTemplate rabbitTemplate) {
11        this.rabbitTemplate = rabbitTemplate;
12    }
13
14    public void publishCreatedOrder(long orderId, BigDecimal total) {
15        OrderCreatedMessage message = new OrderCreatedMessage(orderId, total);
16
17        rabbitTemplate.convertAndSend(
18                RabbitConfig.EXCHANGE_NAME,
19                RabbitConfig.ROUTING_KEY,
20                message
21        );
22    }
23}

convertAndSend is convenient because it works with Spring’s message converters rather than forcing you to serialize manually in every sender.

Prefer JSON Payloads Over Java Serialization

For most service-to-service messaging, JSON is easier to inspect and safer to integrate than default Java serialization.

1import org.springframework.amqp.support.converter.Jackson2JsonMessageConverter;
2import org.springframework.context.annotation.Bean;
3
4@Bean
5Jackson2JsonMessageConverter jackson2JsonMessageConverter() {
6    return new Jackson2JsonMessageConverter();
7}

With that in place, a compact payload type works well.

1import java.math.BigDecimal;
2
3public record OrderCreatedMessage(long orderId, BigDecimal total) {
4}

That keeps the on-the-wire message readable and makes cross-service integration much easier.

Receive Messages with @RabbitListener

The consumer side is usually implemented with @RabbitListener.

1import org.springframework.amqp.rabbit.annotation.RabbitListener;
2import org.springframework.stereotype.Component;
3
4@Component
5public class OrderCreatedListener {
6
7    @RabbitListener(queues = RabbitConfig.QUEUE_NAME)
8    public void onMessage(OrderCreatedMessage message) {
9        System.out.printf(
10                "Received order %d with total %s%n",
11                message.orderId(),
12                message.total()
13        );
14    }
15}

Spring creates the listener container, subscribes to the queue, and invokes your method when a message arrives.

Think About Failure Handling Early

Messaging design becomes serious when processing can fail. A consumer that crashes after updating one table but before finishing all side effects may see the same message again. That means message handlers should generally be idempotent or at least duplicate-safe.

You should also decide what happens after repeated failures. A message should not usually loop forever with no observability. Dead-letter queues, retry policies, and alerting are part of the design, not optional cleanup.

The sender and receiver code may look simple, but the production behavior is defined by these operational choices.

Keep Business Logic Out of Messaging Glue

A healthy Spring AMQP design keeps infrastructure in configuration classes, publishing in sender services, and business logic in application services called by listeners. If the listener method grows into a large transaction script, the messaging layer becomes hard to test and harder to reason about.

The listener should usually validate the message shape, call a service, and let that service own the business workflow.

Common Pitfalls

• Sending directly to queues everywhere and never defining exchanges or routing explicitly.
• Using Java object serialization when a JSON payload would be easier to inspect and integrate.
• Putting too much domain logic directly inside listener methods.
• Ignoring idempotency and assuming messages are processed exactly once.
• Leaving failures in endless redelivery loops without a retry or dead-letter strategy.

Summary

• Spring AMQP typically uses queues, exchanges, and bindings plus a sender and listener.
• 'RabbitTemplate publishes messages, and @RabbitListener consumes them.'
• JSON conversion is usually a better default than Java serialization.
• Reliable messaging requires thought about retries, duplicates, and dead-letter behavior.
• Keep the messaging layer thin and let application services own the business work.