Reactive Source-Sink: Benchmarking Backpressure in Pulsar Pipelines

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.

In Reactive Telegram Client we built a reactive pipeline that feeds messages into Pulsar. In Pulsar vs Kafka Part 2 we benchmarked broker throughput under load. This post focuses on what happens between those two endpoints: a source-to-sink pipeline that reads from one Pulsar topic and writes to another, benchmarked rigorously with JMH.

All benchmarks, source code, and JMH result files are available in the reactive-source-sink repository.

The Problem — Source to Sink

A source-to-sink pipeline is the fundamental building block of stream processing. Every Flink job, every Kafka Streams topology, every reactive microservice does this: consume from one endpoint, optionally transform, produce to another.

But “source” and “sink” are not limited to message brokers. The same pattern appears everywhere data flows between components with different throughput capacities:

• Broker to Broker — Kafka topic to Pulsar topic, or between clusters in different regions
• Broker to Database — consuming events and writing to PostgreSQL, Cassandra, or Elasticsearch
• Service to Service — an HTTP or gRPC microservice that reads from an upstream and writes to a downstream, where the downstream may be slower, rate-limited, or degraded
• Database to Broker — CDC (Change Data Capture) pipelines reading a binlog and publishing to Kafka/Pulsar
• API Gateway to Backend — an edge service accepting client requests at a rate the backend cannot sustain

      graph LR
    subgraph "Sources"
        S1["Message Broker"]
        S2["Database / CDC"]
        S3["HTTP API"]
    end

    subgraph "Pipeline"
        C["Reactive Source<br/><i>demand-driven</i>"] --> T["Transform"] --> P["Reactive Sink<br/><i>backpressured</i>"]
    end

    subgraph "Sinks"
        D1["Message Broker"]
        D2["Database"]
        D3["Microservice"]
    end

    S1 & S2 & S3 --> C
    P --> D1 & D2 & D3
    

In every case, the critical property is that the source and sink have different throughput capacities. If the source reads faster than the sink can write, messages accumulate somewhere. Where they accumulate — and how that accumulation is controlled — is the entire difference between a system that works and one that crashes at 3 AM.

In a microservice architecture, this problem compounds. Service A calls Service B, which calls Service C. If Service C slows down and Service B has no backpressure, B’s memory grows until it crashes — then A has no downstream, and the failure cascades back up the chain. Reactive backpressure turns this into a controlled slowdown: C signals B to slow down, B signals A, and the entire pipeline throttles to the speed of the slowest component.

We benchmark this pattern using Pulsar as both source and sink, but the Publisher and Subscriber implementations we build are broker-agnostic. The same demand-driven source can wrap a JDBC connection, an HTTP client, or any I/O channel.

Project Structure

The benchmark project is split into four Gradle modules — one shared core and one per approach. Each pipeline module declares its own JMH benchmark and produces a separate results.json file.

reactive-source-sink/
├── core/                    # Shared interfaces, BenchmarkContext, models
├── blocking/                # Plain blocking pipeline + JMH benchmark
├── flux-wrapped/            # Flux-wrapped blocking pipeline + JMH benchmark
└── reactive-backpressure/   # Custom Publisher/Subscriber + JMH benchmark

The core module provides a BenchmarkContext that creates a Pulsar client, a source consumer, a sink producer (with batching enabled — 1000 messages per batch, 1ms publish delay), and a daemon background feeder that continuously publishes 1 KB messages into the source topic so consumer.receive() never starves during a benchmark run.

public BenchmarkContext(int messageSize) throws PulsarClientException {
    this.consumer = config.getPulsarClient()
            .newConsumer(Schema.BYTES)
            .topic(sourceTopic)
            .subscriptionName(subscriptionName)
            .subscriptionType(SubscriptionType.Shared)
            .receiverQueueSize(10_000)
            .subscribe();

    this.producer = config.getPulsarClient()
            .newProducer(Schema.BYTES)
            .topic(sinkTopic)
            .enableBatching(true)
            .batchingMaxMessages(1000)
            .batchingMaxPublishDelay(1, TimeUnit.MILLISECONDS)
            .blockIfQueueFull(true)
            .maxPendingMessages(50_000)
            .create();

    // Background feeder keeps source topic continuously populated
    this.feederThread = new Thread(() -> runFeederLoop(payload));
    this.feederThread.setDaemon(true);
    this.feederThread.start();
}

This setup is key to fair JMH benchmarking — the consumer never blocks waiting for messages, so we measure the pipeline cost, not the broker latency.

Three Approaches

Approach 1 — True Reactive (Backpressure)

The reactive approach implements the Reactive Streams specification directly with a custom Publisher<byte[]>. The JMH benchmark builds a fresh pipeline per invocation:

@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.SECONDS)
@Warmup(iterations = 1, time = 30, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 3, time = 30, timeUnit = TimeUnit.SECONDS)
@Fork(1)
@Threads(1)  // parallelism is inside the flux
@State(Scope.Benchmark)
public class ReactiveJmhBenchmark {

    private static final int MESSAGE_SIZE = 1024;
    private static final int SOURCE_SCHEDULER_THREADS = 2;
    private static final int PIPELINE_SCHEDULER_THREADS = 8;
    private static final int BATCH_SIZE = 1024;
    private static final int FLATMAP_CONCURRENCY = 256;

    @Benchmark
    @OperationsPerInvocation(BATCH_SIZE)
    public void runFlux(Blackhole bh) {
        PulsarReactiveSource source = new PulsarReactiveSource(ctx.consumer, sourceScheduler);

        Flux<MessageId> sendFlux = Flux.from(source)
                .publishOn(pipelineScheduler)
                .map(BenchmarkMessage::deserialize)
                .flatMap(msg -> Mono.fromCompletionStage(
                        () -> ctx.producer.newMessage()
                                .key(msg.getKey())
                                .value(msg.serialize())
                                .sendAsync()),
                        FLATMAP_CONCURRENCY)
                .doOnNext(id -> processed.incrementAndGet());

        StepVerifier.create(sendFlux)
                .expectNextCount(BATCH_SIZE)
                .thenCancel()
                .verify(VERIFY_TIMEOUT);

        bh.consume(sendFlux);
    }
}

The @OperationsPerInvocation(BATCH_SIZE) annotation tells JMH that each runFlux() invocation processes 1024 messages, so the reported ops/s reflects per-message throughput. StepVerifier.expectNextCount(BATCH_SIZE).thenCancel() is the JMH-friendly way to bound work — it subscribes, waits for exactly 1024 onNext signals, then cancels the subscription.

The pipeline does four things per message:

1. Source emits raw bytes — the custom PulsarReactiveSource reads byte[] directly from the Pulsar consumer with no deserialization on the receive thread (the receive loop stays cheap and CPU-bound)
2. publishOn(pipelineScheduler) — switches threads from the source receive thread to a dedicated pipeline scheduler (8 threads). The deserialization and downstream operators all run on the pipeline scheduler
3. map(deserialize) — converts raw bytes into BenchmarkMessage on the pipeline scheduler
4. flatMap(sendAsync, 256) — fires up to 256 concurrent async sends. Mono.fromCompletionStage wraps Pulsar’s sendAsync() future without blocking any thread

The Source — Demand-Driven Receive Loop with Batch Drain

The PulsarReactiveSource is a Publisher<byte[]> (not Publisher<BenchmarkMessage> — deserialization is intentionally pushed downstream to avoid CPU work on the receive thread):

public class PulsarReactiveSource implements Publisher<byte[]> {

    private static final int RECEIVE_TIMEOUT_MS = 100;
    private static final int MAX_BATCH_DRAIN = 32;

    private final Consumer<byte[]> consumer;
    private final Scheduler scheduler;

    public PulsarReactiveSource(Consumer<byte[]> consumer, Scheduler scheduler) {
        this.consumer = consumer;
        this.scheduler = scheduler;
    }

    private void receiveLoop() {
        while (!cancelled.get()) {
            if (demand.get() == 0) {
                LockSupport.park(this);  // sleep until demand arrives
                continue;
            }

            // Block briefly for the first message of this drain cycle
            Message<byte[]> first = consumer.receive(RECEIVE_TIMEOUT_MS, TimeUnit.MILLISECONDS);
            if (first == null) continue;
            emit(first);

            // Opportunistic batch drain — pull more from prefetch buffer
            int batched = 1;
            while (batched < MAX_BATCH_DRAIN && demand.get() > 0) {
                Message<byte[]> next = consumer.receive(0, TimeUnit.MILLISECONDS);
                if (next == null) break;
                emit(next);
                batched++;
            }
        }
    }
}

Three optimizations make this efficient:

1. Park-on-zero-demand. When demand reaches zero, LockSupport.park() puts the thread to sleep with nanosecond overhead. No polling, no busy-wait.
2. Opportunistic batch drain. After the blocking receive() returns the first message, the loop polls non-blocking (receive(0, MILLISECONDS)) for up to 31 more messages from Pulsar’s local prefetch buffer. One blocking call serves a batch of up to 32 messages.
3. No deserialization on the source thread. The source emits raw byte[] and lets the downstream publishOn switch threads before deserializing. This keeps the receive loop tight.

      sequenceDiagram
    participant B as Pulsar Broker
    participant S as Source Thread<br/>(parks when demand=0)
    participant PS as Pipeline Scheduler<br/>(8 threads)
    participant SK as flatMap(256)
    participant T as Sink Topic

    Note over SK: request(1024) to source
    S->>B: receive() — first message
    B-->>S: bytes
    Note over S: drain up to 32 more<br/>(non-blocking poll)
    S->>PS: emit byte[]
    PS->>PS: deserialize on pipeline thread
    PS->>SK: flatMap with concurrency 256
    SK->>T: sendAsync() [non-blocking]
    T-->>SK: ack
    Note over S: when demand low,<br/>park()
    Note over S,T: Reads, deserialization,<br/>and writes overlap
    

Approach 2 — Flux-Wrapped Blocking (No Real Backpressure)

This approach uses the plain blocking Pulsar client wrapped in Reactor operators. It looks reactive. It is not.

@BenchmarkMode(Mode.Throughput)
@Threads(1)
@State(Scope.Benchmark)
public class FluxWrappedJmhBenchmark {

    private static final int MESSAGE_SIZE = 1024;
    private static final int PARALLELISM = 8;
    private static final int BATCH_SIZE = 1024;

    @Benchmark
    @OperationsPerInvocation(BATCH_SIZE)
    public void runFlux(Blackhole bh) {
        Long processed = Flux.<byte[]>generate(sink -> {
                    try {
                        Message<byte[]> msg = ctx.consumer.receive(5, TimeUnit.SECONDS);
                        if (msg != null) {
                            sink.next(msg.getData());
                            ctx.consumer.acknowledgeAsync(msg);
                        } else {
                            sink.complete();
                        }
                    } catch (PulsarClientException e) {
                        sink.error(e);
                    }
                })
                .take(BATCH_SIZE)
                .parallel(PARALLELISM)
                .runOn(scheduler)
                .flatMap(bytes -> Mono.fromCallable(() -> {
                    ctx.producer.send(bytes);
                    return bytes;
                }))
                .sequential()
                .count()
                .block();

        bh.consume(processed);
    }
}

Flux.generate is pull-based and synchronous — it calls the generator function once per downstream request. This looks like backpressure: downstream pulls, upstream responds.

But consumer.receive() does not know about downstream demand. It blocks the calling thread until a message arrives or the timeout expires. The Pulsar consumer’s prefetch buffer fills independently of anything Reactor does. The parallel(8).runOn(scheduler) rails distribute the messages across 8 threads, but each thread blocks on producer.send() for the entire send duration.

      graph TD
    subgraph "What You See (Reactive Chain)"
        FG["Flux.generate()"] -->|"pull-based"| TK["take(1024)"]
        TK --> PR["parallel(8)"]
        PR --> RO["runOn(scheduler)"]
        RO --> FM["flatMap(send)"]
    end

    subgraph "What Actually Happens"
        BRC["consumer.receive()<br/><b>BLOCKS thread</b>"]
        BRQ["Pulsar prefetch buffer<br/><i>fills independently of demand</i>"]
        BPS["producer.send() x8<br/><b>BLOCKS 8 threads</b>"]
        BSCH["scheduler<br/><i>cannot overlap blocked sends</i>"]

        BRC -.-> BRQ
        BPS -.-> BSCH
    end

    style BRC fill:#8b0000,color:#fff
    style BPS fill:#8b0000,color:#fff
    style BRQ fill:#8b4513,color:#fff
    style BSCH fill:#8b4513,color:#fff
    

The trap is subtle. The parallel(8) operator looks like it adds parallelism, but each rail still blocks on a synchronous producer.send(). With 8 rails and 8 threads, you get exactly 8 in-flight sends — no more. Compare this to the reactive approach, which maintains 256 concurrent in-flight sendAsync() operations on a single source thread.

Approach 3 — Plain Blocking (JMH Threads)

No pretense of reactive. JMH manages 8 worker threads via @Threads(8), and each invocation does exactly one receive-send pair.

@BenchmarkMode(Mode.Throughput)
@Threads(8)
@State(Scope.Benchmark)
public class BlockingJmhBenchmark {

    private static final int MESSAGE_SIZE = 1024;
    private static final int RECEIVE_TIMEOUT_SECONDS = 5;

    @Benchmark
    public void readWrite(Blackhole bh) throws Exception {
        Message<byte[]> msg = ctx.consumer.receive(RECEIVE_TIMEOUT_SECONDS, TimeUnit.SECONDS);
        if (msg == null) return;
        ctx.producer.send(msg.getData());
        ctx.consumer.acknowledge(msg);
        bh.consume(msg);
    }
}

This is the baseline. Each readWrite() invocation processes exactly one message — there is no @OperationsPerInvocation annotation because each call is one operation. JMH spawns 8 threads, each running readWrite() in a tight loop. The pipeline is sequential per worker — throughput is bounded by the round-trip latency of receive() + send().

Benchmark Setup

All three benchmarks run as JMH microbenchmarks against the same Pulsar instance with identical JVM settings.

      graph LR
    subgraph "Test Host (ms-a2-alpha)"
        HW["AMD Ryzen 9 7945HX<br/><i>16 cores / 32 threads</i><br/><i>44 GB RAM / NVMe SSD</i>"]
    end

    subgraph "Docker"
        PS["Pulsar 3.3.4 Standalone<br/><i>6 GB heap / G1GC</i><br/><i>4 CPU cores</i>"]
    end

    subgraph "JMH Benchmark JVMs"
        A1["Reactive<br/>BATCH_SIZE=1024"]
        A2["Flux-Wrapped<br/>BATCH_SIZE=1024"]
        A3["Blocking<br/>@Threads(8)"]
    end

    A1 & A2 & A3 --> PS
    

Host Hardware

JMH Configuration

Test Parameters

Throughput Results

JMH Reported Scores

JMH reports its primary metric as ops/s. For the blocking benchmark, each invocation is one message, so ops/s directly equals msg/sec. For the reactive and Flux-wrapped benchmarks, each invocation processes a batch of 1024 messages — to translate the JMH score into per-message throughput, we multiply by BATCH_SIZE.

Throughput Comparison

Percentages compare each approach to Reactive.

Three patterns dominate:

1. Reactive is 27x faster than the wrapper. The custom Publisher/Subscriber pattern with non-blocking sendAsync() and a 256-slot concurrency window dramatically outperforms blocking producer.send() on 8 parallel rails.
2. Flux-wrapped is 917x faster than blocking. Even fake reactive patterns beat sequential blocking — the parallel(8) operator at least gets 8 concurrent sends going, while pure blocking serializes everything per worker.
3. Reactive is the most stable. JMH’s iteration variance is just 1.7% for reactive vs 4.7% for blocking — the demand-driven design produces predictable per-iteration throughput.

Why the Difference Is So Large

The 27x gap between reactive and Flux-wrapped, and the 24,000x gap between reactive and blocking, deserve explanation.

Reactive: Sliding Window of 256 Async Sends

The reactive pipeline maintains 256 concurrent in-flight sendAsync() operations regardless of how many test threads are running. Each send is non-blocking — it returns a CompletableFuture immediately, and the source thread is free to receive more messages while previous sends are still in flight. Pulsar’s producer batches these aggressive sends at the broker level (1000 messages per batch, 1ms publish delay), so each TCP roundtrip carries up to 1 MB of payload.

The combination of:

• Source-side batch drain (32 messages per blocking receive())
• Pipeline scheduler (8 threads handling deserialization and operator chaining)
• Sink-side concurrency (256 in-flight async sends)
• Pulsar producer batching (1000 messages per network call)

…produces a pipeline where reads, deserialization, and writes all overlap continuously. There is essentially no idle time on any thread.

Flux-Wrapped: 8 Threads Blocked on Synchronous Sends

The parallel(8).runOn(scheduler).flatMap(send) chain looks parallel, but each of the 8 rails calls a blocking producer.send(). Even with Pulsar producer-side batching, each rail can only complete one send-batch round-trip at a time. The throughput ceiling is roughly 8 × (1 / send-latency) — for typical localhost Pulsar, that’s a few hundred KB per second per rail.

The Flux.generate source compounds the problem: each call to consumer.receive() blocks the generator thread, so the source-side parallelism is limited too. The pipeline is bottlenecked at both ends.

Blocking: One Message at a Time per Worker

The blocking benchmark has 8 JMH threads, each running:

msg = consumer.receive();
producer.send(msg.getData());
consumer.acknowledge(msg);

There is no overlap between receive and send within a worker. Each message round-trips through the broker before the next one starts. With 8 workers and a single-partition topic, throughput is gated by Pulsar’s per-subscriber dispatch rate — and for blocking sync sends, that comes out to about 30 msg/sec per worker.

      graph LR
    subgraph "Reactive: Async Overlap"
        direction TB
        R1["Source: 32-msg drain<br/><b>1 thread</b>"]
        R2["Pipeline: 8 threads<br/><b>deserialize</b>"]
        R3["Sink: 256 in-flight<br/><b>sendAsync()</b>"]
        R4["Pulsar batch<br/><b>1000 msg/network call</b>"]
        R1 --> R2 --> R3 --> R4
    end

    subgraph "Flux-Wrapped: 8 Blocked Rails"
        direction TB
        W1["Source: Flux.generate<br/><b>blocks on receive()</b>"]
        W2["parallel(8).runOn"]
        W3["flatMap(send)<br/><b>8 blocked threads</b>"]
        W1 --> W2 --> W3
    end

    subgraph "Blocking: Sequential per Worker"
        direction TB
        B1["8 JMH threads"]
        B2["receive → send → ack<br/><b>fully synchronous</b>"]
        B1 --> B2
    end

    style R1 fill:#2d5016,color:#fff
    style R2 fill:#2d5016,color:#fff
    style R3 fill:#2d5016,color:#fff
    style R4 fill:#2d5016,color:#fff
    style W1 fill:#5c3a1a,color:#fff
    style W2 fill:#5c3a1a,color:#fff
    style W3 fill:#5c3a1a,color:#fff
    style B1 fill:#8b0000,color:#fff
    style B2 fill:#8b0000,color:#fff
    

When Backpressure Actually Saves You

The benchmark measures the happy path with a fast sink. Failure modes that show up under sink degradation — the entire reason backpressure exists — do not appear when the sink is as fast as the source. Here is what would happen in a longer-running production pipeline.

Memory Bloat and OOM

A consumer reading 1 KB messages at 6.29M msg/sec accumulates ~6 GB/sec in JVM memory if the sink stalls. The benchmark’s -Xmx4g heap fills in well under a second of complete sink stall. With backpressure, the source parks when the sink stops requesting and messages stay in Pulsar — which is designed to buffer to disk via BookKeeper. With the wrapper, every byte sits in JVM memory until the sink recovers or the JVM dies.

Cascading Failures in Microservices

In a multi-service pipeline — Source A -> Transform -> Sink B — if Sink B degrades and Transform does not propagate backpressure, Transform’s memory grows until it crashes. Then Source A has no consumer, and Pulsar’s retry policy kicks in. When Transform restarts, it replays the backlog plus new messages. The cycle repeats.

      graph TD
    A["Source A<br/><i>1,000 msg/sec</i>"] --> T["Transform Service<br/><i>no backpressure</i>"]
    T --> B["Sink B<br/><i>degraded: 100 msg/sec</i>"]

    T -->|"900 msg/sec<br/>accumulating"| MEM["JVM Heap Growing"]
    MEM --> OOM["OutOfMemoryError"]
    OOM --> RESTART["Service Restart"]
    RESTART -->|"replay backlog<br/>+ new messages"| T

    style OOM fill:#8b0000,color:#fff
    style MEM fill:#8b4513,color:#fff
    

With true reactive backpressure, the Transform service signals Source A to slow down. Source A signals its upstream. The entire pipeline throttles to the speed of the slowest component. No memory growth, no restarts, no replay storms.

When You Do Not Need Reactive

Not every pipeline needs a custom Publisher and Subscriber. Here is an honest assessment:

• < 1,000 msg/sec on matched hardware: plain blocking with a JMH-style thread pool reaches 253 msg/sec at 8 threads. For CRUD-style microservices that fit this envelope, the operational simplicity is worth the throughput ceiling.
• Short-lived batch jobs: if the pipeline runs for seconds, memory growth is irrelevant. Use whatever is simplest.
• Prototype or proof-of-concept: Flux.generate wrappers are quick to write and demonstrate the concept. Just do not ship them to production expecting backpressure or competitive throughput.

Reactive backpressure pays off when:

• Source and sink have different performance characteristics (remote cluster, database, HTTP API)
• The sink has variable latency (network jitter, GC pauses, load spikes)
• The pipeline runs continuously for hours or days
• You cannot afford restarts (financial systems, real-time analytics, SLA-bound services)
• Throughput matters — a 27x speedup over the next-best alternative is hard to ignore

Choosing Your Approach

      graph TD
    START["Source-Sink Pipeline"] --> Q1{"< 200 msg/sec?"}
    Q1 -->|Yes| BLOCK["Plain Blocking<br/><i>JMH-style threads</i>"]
    Q1 -->|No| Q2{"Production<br/>workload?"}
    Q2 -->|Yes| REACTIVE["True Reactive<br/><i>Custom Publisher + sendAsync</i>"]
    Q2 -->|No| Q3{"Quick prototype?"}
    Q3 -->|Yes| WRAPPER["Flux-Wrapped Blocking<br/><i>no real backpressure</i>"]
    Q3 -->|No| REACTIVE

    style REACTIVE fill:#2d5016,color:#fff
    style BLOCK fill:#1a3a5c,color:#fff
    style WRAPPER fill:#5c3a1a,color:#fff
    

Conclusion

The JMH numbers tell an unambiguous story: a properly implemented reactive pipeline is 27x faster than wrapped blocking and 24,855x faster than plain blocking. The reactive approach hits 6.29 million messages per second on a single-machine Pulsar setup with 1 KB messages — three orders of magnitude beyond what the wrapped approach can achieve.

The key insight is architectural. The reactive pipeline maintains 256 concurrent in-flight async sends, lets reads and writes overlap continuously, batches at both the source (32-message drain) and the sink (Pulsar’s 1000-message producer batching), and never blocks a thread on producer.send(). The Flux-wrapped approach, despite using parallel(8) rails, achieves only 8 concurrent sends because each rail is bottlenecked on a blocking send() call. Plain blocking serializes everything per worker.

Wrapping blocking code in Flux.generate and Mono.fromCallable does not confer backpressure. It confers the syntax of reactive code without the semantics. The Pulsar broker keeps pushing, the prefetch buffer keeps filling, and each producer.send() blocks a thread regardless of what your flatMap concurrency limit says. The benchmark cannot show the catastrophic failure mode because the sink is as fast as the source — but in production with a degraded sink, the wrapper’s memory grows unbounded while the reactive pipeline self-regulates.

The reactive approach is not just safer. It is dramatically faster. There is no tradeoff to make.

References

1. Reactive Streams Specification
2. Project Reactor — CoreSubscriber
3. Project Reactor — Flux.generate
4. Apache Pulsar — Producer.sendAsync()
5. JMH — @OperationsPerInvocation
6. JMH — Best Practices for Microbenchmarks
7. LockSupport.park / unpark
8. Reactive Telegram Client: Polling, Pipelines, and Pulsar
9. Apache Pulsar vs Kafka: Benchmarking — Part 2
10. Benchmark Source Code