spring-messaging-demo/README.md

spring-messaging-demo

Companion code for the messaging series on ankurm.com. Each directory is a self-contained Maven project for one article, with its own pom.xml and its own captured output, regenerated from the test suite rather than typed by hand. Most modules keep that output under docs/output/ alongside numbered documentation chapters; saga/ keeps it directly under output/ instead, with the equivalent depth in the article's own accordion sections.

Module	Article	What it demonstrates
kafka-basics/	Spring Boot 4.1 and Apache Kafka: Producer, Consumer and Serialisation from Scratch	The on-ramp: what the starter gives you, the two Jackson serializer families, where a key lands and why, and which defaults are Kafka's rather than Spring's
kafka-error-handling/	Kafka Error Handling with Spring Kafka 4.1: DLT, Retry Topics and Poison Pills	What the default error handler really does, why a poison pill stops a partition, and what blocking retries cost that retry topics do not
rabbitmq/	Spring Boot and RabbitMQ: Exchanges, Queues, Bindings and a Working Dead-Letter Queue	All four exchange types against a real broker, manual acknowledgement, and a dead-letter path exercised through both rejection and TTL expiry
sse-websocket/	Server-Sent Events and WebSocket on Spring Boot 4: SseEmitter, STOMP, and Which to Pick	The two browser-facing options side by side: the SSE lifecycle and the three ways a stream ends, STOMP's routing defaults, and the size limit that is enforced by Tomcat rather than by Spring
protocol-comparison/	RSocket vs gRPC vs WebSocket on Spring Boot 4.1: When Each One Wins	One application serving the same two operations over all three, benchmarked in one JVM, ending in the only measurement that transfers off the box: what each server produces for a consumer that asked for a hundred
broker-comparison/	Kafka vs RabbitMQ vs Pulsar for Java Teams: A Decision Framework with Benchmarks	The three brokers measured side by side on ordering, replay, consumer scaling and operational footprint, ending in a decision table where every row has a transcript behind it
saga/	Saga Pattern in Spring Boot: Orchestration vs Choreography with Kafka	The same order/payment/inventory saga built twice against a real broker — choreography and orchestration — driven through the same inventory failure so the compensating transaction can be compared side by side, plus a real duplicate-delivery test for the idempotent-consumer problem

The brokers make an instructive set. Kafka's consumer holds an offset and the broker remembers nothing about individual records; RabbitMQ's broker owns the message until it is acknowledged and can route, expire and dead-letter it on its own; Pulsar keeps the log but lets each subscriber choose how it is read. Almost every difference in how you handle failure follows from those three sentences — which is why Kafka needs a retry topic to do what RabbitMQ does with a queue argument, and why broker-comparison is mostly an argument about where a message lives.

The last two modules are about the other kind of messaging — a connection rather than a broker — and they are deliberately adjacent to the broker modules, because the question "should this be a topic or a stream?" is answered by whether anything needs to survive a dropped connection. Nothing in sse-websocket or protocol-comparison persists a single message.

They are meant to be read in order. kafka-basics establishes that the default acknowledgement mode is BATCH and therefore that delivery is at-least-once; everything the error-handling module does exists because of that one sentence.

Common ground

All modules target the same verified stack: JDK 25 (Temurin 25.0.4.1+1), Spring Boot 4.1.1, Spring Framework 7.0.9. Versions were read from maven-metadata.xml on Maven Central and from Boot's own spring-boot-dependencies POM, rather than from release announcements.

Every module runs its broker without Docker, so the transcripts can be regenerated on any machine with a JDK: Kafka via the in-process KRaft broker in spring-kafka-test, RabbitMQ and Pulsar via real brokers started by the modules' own scripts. Each module also ships a Testcontainers configuration for the cases where the deployed image is what you need to test against.

Licence

MIT — see LICENSE.