Pulsar

Introduction Does wrapping a blocking Pulsar consumer in Flux.generate give you backpressure? Does adding backpressure cost you throughput? The first answer is no — wrapping blocking calls in Reactor operators creates something that looks reactive but behaves like a fire hose. The second answer is also no: a properly implemented reactive pipeline is dramatically faster than both alternatives. Our JMH benchmark shows the reactive approach hitting 6.29 million messages/sec — 27x faster than the Flux-wrapped approach (232k msg/sec) and 24,800x faster than plain blocking (253 msg/sec). The reactive pipeline is faster because it does less work per message: no thread blocking, no Mono.fromCallable allocation, no boundedElastic scheduling overhead. ...

Introduction Part 1 compared the architectural foundations of Kafka and Pulsar — storage models, subscription types, multi-tenancy, and client design. That was theory. This post puts those differences under load. We will run the same workloads against both brokers on identical hardware, using a reactive benchmark framework built with Project Reactor. The goal is not to crown a winner — it is to see where architectural decisions become measurable. Specifically, we will look at: ...

From Design to Implementation In the previous article, I outlined the design goals and high-level architecture of a reactive Telegram bot framework — why non-blocking I/O matters, how separating polling from processing enables horizontal scaling, and why sealed interfaces make response dispatch type-safe at compile time. That article showed simplified code to explain the concepts. This one goes deeper. We will walk through the actual implementation: how Flux.create and expand drive the polling loop with back-pressure, how atomic variables coordinate concurrent state without locks, how the channel abstraction separates read and write concerns, and how Apache Pulsar’s reactive client integrates natively with Project Reactor. ...

Introduction Kafka has been the default choice for event streaming for over a decade. It earned that position — it solved real problems at LinkedIn-scale when nothing else could, and the ecosystem built around it is massive. If you are building a new system today and someone says “use Kafka,” that is not bad advice. But it is incomplete advice. Apache Pulsar was created at Yahoo in 2013 to solve problems that Kafka’s architecture made structurally difficult: multi-tenancy across thousands of topics, independent scaling of storage and compute, and geo-replication as a first-class feature rather than an afterthought. It was open-sourced in 2016 and became a top-level Apache project in 2018. ...