Engine Rooms of Asynchronous Processing (part 1): Reactor Pattern Conceptual Overview

30 Aug, 2025

Intro

"Engine Rooms of Asynchronous Processing" are series of articles exploring patterns used to facilitate concurrent asynchronous programming. The series aims to (eventually) provide a clear understanding of well-established patterns in this space and explore implementing them from scratch.

The first group of these articles will explore the Reactor pattern.

Reactor

Image is AI generated

Components of a Reactor

Resources: Sources that produce I/O events

Also known as Handles, these are sources that need to be monitored. They are simply places where you expect I/O operations to occur.

Event Demultiplexer: Resources whistle blower

Watch over a set of Resources in synchronous fashion. Synchronous as it blocks the thread it is running in, not resuming until there are some I/O events ready from Resources.

Event Handlers: Specific I/O event Caretaker

These are code that should be executed when a specific type of I/O event happens on a specific resource.

Reactor: The glue

Reactor brings everyone together: Resources and Event Handlers. It connects the dots, by Event Demultiplexer: in a for-ever loop, wait for some I/O events to happen on all Resources, execute related event handlers for each one.

Flows inside Reactor

Following interactions happen within a cyclical Reactor flow:

1. Registration:
   • Client expresses their interest in Events: For a specific Resource, What Handlers should be executed for what specific I/O event type?
2. Event Loop:
   • The reactor hits the ground running: Having a map of Resource events to Event Handlers, A for-ever loop starts within the reactor.
3. Waiting for Events:
   • Monitor I/O events in Resources while being nice to CPU: Using the Event Demultiplexer, Reactor waits until some events are available. This step is where Reactor pattern tries its best to not waste any CPU cycle waiting for I/O events to become available. Note that the blocking call to Demultiplexer is made at this point, and the reactor is waiting for I/O events to become available.
4. Dispatching:
   • Resources have some events: Event Demultiplexer returns from the previous round of monitoring events, handing over a list of Resources (aka Handles) that have some events ready to be processed.
5. Executing Handlers:
   • Reactor runs interested Handler(s): At this point, the Reactor is ready to pass on the Resource that has some event to the handler that was previously registered in the Registration step. This is also recognized as executing the callback.

After handlers finish executing (in essence handling the event), Reactor then returns the control to step 2.

Following sequence diagram summarizes the reactor pattern:

Next

For the next part, we will look at how we can implement this pattern using JDK, stay tuned ;).