Messaging / Event-Driven Architecture

Messaging for Spring Boot microservices with Kafka and RabbitMQ

Spring Middleware provides a platform model for messaging in Spring Boot microservices. It standardizes publishers, consumers, and event-driven patterns across Kafka and RabbitMQ, including retry strategies, dead-letter handling, and explicit runtime behavior.

Explore messaging View architecture

Kafka messaging RabbitMQ messaging Event-driven architecture Publishers and consumers Retry and dead-letter handling Platform messaging patterns

What messaging means here

Messaging in Spring Middleware is not just a wrapper around broker clients. The goal is to standardize how services publish events, consume messages, attach cross-cutting behavior, and manage infrastructure concerns such as topics, queues, bindings, retries, and dead-letter routing.

Keep publisher and consumer behavior explicit
Reduce repeated broker-specific setup in each service
Support both event-driven and integration-style messaging
Keep runtime hooks available for tracing, metrics, and error handling

Two messaging styles

Spring Middleware supports two complementary messaging models. Kafka is oriented to event streams and publisher/subscriber configuration. RabbitMQ is exposed through a JMS-like, annotation-driven resource model with producers, consumers, handlers, listeners, and lifecycle control.

Kafka: topic-based event publishing and subscriber registration.
RabbitMQ: resource-driven producers and consumers with explicit lifecycle and processing hooks.
Both: platform conventions instead of one-off per-service wiring.

High-level messaging view

Services publish or consume messages through platform-aligned abstractions, while broker-specific behavior remains visible and configurable.

Kafka and RabbitMQ in the platform

Both integrations are first-class, but they solve different runtime problems and expose different extension points.

Kafka

The Kafka integration is configuration-driven and opinionated around publishers, subscribers, topic creation, event envelopes, and consumer error handling.

Named publishers registered from configuration
Subscriber endpoints wired from topic and group settings
Event envelopes with eventId, eventType, timestamp, traceId, and payload
Retry and dead-letter behavior through module configuration

RabbitMQ

The RabbitMQ integration provides a JMS-like model with annotation-driven producers, consumers, handlers, listeners, resource discovery, connection pooling, and explicit lifecycle control.

@JmsProducer and @JmsConsumer resource model
Marker-based handlers, listeners, and error handlers
Transacted sessions and acknowledge modes
Durable queues, exchanges, bindings, and cleanup strategies

Kafka runtime model

Kafka support is oriented around configuration-backed publishers and subscribers, with predictable event metadata and module-level error handling.

Configure topics and publishers

Topic definitions, publisher ids, and subscriber settings are declared under middleware.kafka.

Publish events

A named publisher wraps payloads into an EventEnvelope<T> and sends them through Kafka.

Consume and handle failures

Registered subscribers process records with retry and optional dead-letter behavior when configured.

Kafka configuration example

middleware:
  kafka:
    bootstrap-servers: ${KAFKA_BOOTSTRAP_SERVERS:localhost:9092}
    create-missing-topics: true
    topics:
      catalog-events:
        partitions: 5
        replication-factor: 3
    publishers:
      catalog:
        topic: ${KAFKA_TOPIC_CATALOG:catalog-events}
    subscribers:
      catalog:
        topic: ${KAFKA_TOPIC_CATALOG:catalog-events}
        group-id: ${KAFKA_GROUP_ID_CATALOG:catalog-service-group}
        concurrency: 3

Error handling example

middleware:
  kafka:
    error-handling:
      enabled: true
      max-retries: 3
      retry-backoff-ms: 1000
      dead-letter:
        enabled: true
        suffix: .DLT

RabbitMQ runtime model

RabbitMQ support is annotation-driven and resource-oriented. Producers, consumers, handlers, listeners, and error handlers are discovered and wired at startup.

Discover resources

JmsFactory scans configured packages and creates producers and consumers.

Attach processing hooks

Listeners, handlers, and error handlers are matched through annotation-based rules.

Process, acknowledge, or rollback

Runtime behavior depends on transacted sessions, acknowledgement mode, and configured error handlers.

Consumer example

@JmsConsumer
@JmsDestination(name = "information-uk", destinationType = DestinationType.QUEUE)
public class JmsConsumerUK extends JmsConsumerResource<TestingMessage> {

    public void process(TestingMessage testingMessage, Properties properties) {
        logger.info("Message Received " + testingMessage.getMessage() + "-UK");
    }
}

Handler pattern

@JmsHandler(ConsumerHandler.class)
public class ConsumerHandlerResource<T> extends JmsHandlerResource<String, T> {

    @Override
    public String handleBeforeProcessingMessage(T message, Properties properties) {
        return "dbSession";
    }
}

Messaging conventions in practice

The messaging model is designed to keep services explicit while reducing repeated infrastructure code.

Explicit configuration

Topics, queues, publishers, subscribers, and client behavior are declared clearly instead of being hidden in scattered runtime wiring.

Cross-cutting hooks

Handlers, listeners, and error handlers provide structured extension points for tracing, metrics, transactions, and alerts.

Operational predictability

Retry, acknowledge, rollback, dead-letter routing, and resource lifecycle remain part of the platform model, not implicit broker magic.

Messaging modules

This page is the platform overview. Broker-specific details can live in dedicated pages.

Kafka

Topics, publishers, subscribers, event envelopes, retry, and dead-letter handling.

RabbitMQ

JMS-like resources, producers, consumers, handlers, listeners, acknowledgement, and lifecycle control.