Part 1: Reactive Streams & Basic Concepts

In the previous article, we explored why reactive programming has become increasingly popular. We touched on how it addresses the challenges of building scalable, resilient applications in a world where high concurrency and responsiveness are the norm. Now, let’s dive deeper into the foundational concepts that power reactive programming in Java: the Reactive Streams specification and its essential building blocks.

1. What Are Reactive Streams?

The Reactive Streams specification is a standard for asynchronous stream processing with non-blocking back-pressure. It’s not a framework or a library itself; rather, it’s a set of interfaces and rules that various libraries, such as Project Reactor, Vert.x, RxJava, have implemented.

At its core, Reactive Streams defines four key interfaces:

1. Publisher
2. Subscriber
3. Subscription
4. Processor

1.1 Publisher

A Publisher is a source of data. It can emit 0..N data elements, after which it completes or signals an error. Think of it like a speaker in a conversation, capable of sending messages whenever there is someone willing to listen.

1.2 Subscriber

A Subscriber is the entity that receives data from the Publisher. It has four main methods:

• onSubscribe(Subscription s)
• onNext(T t)
• onError(Throwable t)
• onComplete()

This interface grants the Subscriber the power to request how many items it can handle at a time, which is central to back-pressure.

1.3 Subscription

When a Subscriber and Publisher connect, the bridge between them is the Subscription. The Subscription is responsible for:

• Keeping track of how many items the Subscriber has requested.
• Cancelling the data flow if needed.

1.4 Processor

A Processor is simply a combination of a Subscriber and a Publisher. It can both receive data and publish processed (or transformed) data. This makes it useful for creating pipelines or workflows.

2. Back-Pressure: The Magic Ingredient

Back-pressure is the mechanism that prevents a fast data source (Publisher) from overwhelming a slower consumer (Subscriber). Instead of the Publisher flooding the Subscriber with data, the Subscriber requests items in batches (e.g., 1, 5, 10 at a time), based on its capacity to process them.

In an imperative world, you might have tried to solve this by adding queue buffers or by artificially delaying the producer. With reactive programming, back-pressure is built in through the Subscription.request(long n) method. The Subscriber explicitly dictates how many items it can handle at once, ensuring system stability even under heavy load.

Real-World Analogy

Imagine a coffee shop (Publisher) and a single barista (Subscriber). If the barista can only make one espresso at a time, it’s counterproductive for the coffee shop to push 20 orders simultaneously. With back-pressure, the barista signals the coffee shop: “Hey, I can only handle 3 orders right now.” Once those are done, the barista requests the next batch.

3. A Minimal Reactive Streams Example

Let’s look at a tiny snippet illustrating how these interfaces interact.

Code snippet is available here

How It Works:

1. The SimplePublisher creates a SimpleSubscription and calls subscriber.onSubscribe(subscription).
2. In onSubscribe, the SimpleSubscriber requests 2 items.
3. The subscription, upon request(2), loops and calls subscriber.onNext(...) twice (for values 1 and 2).
4. Every time the subscriber processes 2 items, it requests 2 more. This continues until the SimplePublisher completes at 5.

Though this example is contrived, it demonstrates how each interface interacts and how back-pressure (the request mechanism) works in practice.

4. Where Do We Go From Here?

Now that you understand the basics of Reactive Streams, we can start exploring some robust libraries that make implementing these patterns much easier. In upcoming articles, we’ll:

• Look at Project Reactor, which provides a rich set of operators on top of these core concepts (Mono, Flux, Schedulers, etc.).
• Learn how to build a reactive REST API using Spring WebFlux.
• Dive into the Vert.x ecosystem to see another approach to building responsive, event-driven systems.

By the end of this series, you’ll be well-equipped to decide whether reactive programming is the right choice for your next Java project - and how to implement it effectively if it is.

Key Takeaways

1. Reactive Streams is a specification (not an implementation) that provides core interfaces: Publisher, Subscriber, Subscription, and Processor.
2. Back-pressure is crucial for controlling data flow and preventing overloads.
3. The flow of data in reactive programming is request-driven rather than push-driven.
4. While these core interfaces are vital to understand, real-world usage typically involves libraries like Project Reactor or Vert.x that implement these specs and provide convenient APIs.

In the next article, we’ll get hands-on with Project Reactor, exploring how to set it up, create a simple application, and use its powerful APIs to handle asynchronous data streams.

Stay tuned! If you have any questions or want to share your own experiences, drop a comment below