Understanding Cloud Foundry Core Components, NATS Messaging, and Reactor vs. Proactor I/O Models

Cloud Foundry’s core components include the Router, Cloud Controller, Services, Health Manager, and DEA, all of which communicate via the NATS messaging system or HTTP. NATS is an event‑driven, lightweight publish/subscribe message broker that now supports multi‑node clustering to improve high‑availability.

The platform’s components are built on a publish/subscribe architecture, and NATS provides addressing, discovery, command and control, a central communication system, and support for message publishing and subscription.

When handling web traffic, NATS can operate in two well‑known patterns: the Reactor pattern for synchronous I/O and the Proactor pattern for asynchronous I/O. Before comparing them, the article clarifies the concepts of blocking vs. non‑blocking and synchronous vs. asynchronous operations.

Four I/O models are described: synchronous blocking, synchronous non‑blocking, asynchronous blocking, and asynchronous non‑blocking. Synchronous blocking I/O (e.g., traditional Java IO) forces the process to wait for completion, while synchronous non‑blocking I/O (e.g., Java NIO) allows the process to poll for readiness.

Asynchronous blocking I/O uses system calls like select to wait for kernel notifications, whereas asynchronous non‑blocking I/O lets the kernel notify the application upon completion without the process actively polling.

The Reactor pattern works as follows: 1) the application registers a read/write readiness handler, 2) a demultiplexer waits for events, 3) when an event occurs it notifies the handler, and 4) the handler performs the actual read or write. The Proactor pattern differs by having the application initiate an asynchronous operation, register a completion handler, and let the OS perform the I/O, delivering the result to the handler once finished.

Overall, the article highlights that synchronous vs. asynchronous concerns the interaction between application and kernel, while blocking vs. non‑blocking concerns how system calls behave, and it demonstrates how Reactor and Proactor models allocate the responsibility for actual data transfer.