Ankur Mhatre
e1f8aa7402
Kafka, RabbitMQ and Pulsar measured side by side on ordering, replay and consumer scaling by driving the three client libraries directly, plus an operational-footprint measurement of each broker's own distribution. Nine tests, three brokers started without Docker, and every number in the documentation regenerated by scripts/run-all.sh.
41 lines
3.3 KiB
Markdown
41 lines
3.3 KiB
Markdown
# spring-messaging-demo
|
|
|
|
Companion code for the messaging series on [ankurm.com](https://ankurm.com). Each directory is a
|
|
self-contained Maven project for one article, with its own `pom.xml`, its own numbered
|
|
documentation chapters, and its own captured output under `docs/output/` — regenerated by that
|
|
module's `scripts/run-all.sh`, never typed by hand.
|
|
|
|
| Module | Article | What it demonstrates |
|
|
|---|---|---|
|
|
| [`kafka-basics/`](kafka-basics/README.md) | [Spring Boot 4.1 and Apache Kafka: Producer, Consumer and Serialisation from Scratch](https://ankurm.com/spring-boot-4-1-kafka-producer-consumer-serialisation/) | 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/README.md) | [Kafka Error Handling with Spring Kafka 4.1: DLT, Retry Topics and Poison Pills](https://ankurm.com/spring-kafka-4-1-error-handling-dlt-retry-topics/) | 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/`](rabbitmq/README.md) | [Spring Boot and RabbitMQ: Exchanges, Queues, Bindings and a Working Dead-Letter Queue](https://ankurm.com/spring-boot-rabbitmq-exchanges-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 |
|
|
| [`broker-comparison/`](broker-comparison/README.md) | [Kafka vs RabbitMQ vs Pulsar for Java Teams: A Decision Framework with Benchmarks](https://ankurm.com/kafka-vs-rabbitmq-vs-pulsar-java-decision-framework/) | 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 |
|
|
|
|
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.
|
|
|
|
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](LICENSE).
|