telestion-architecture

ADR-0003: Use NATS as distributed message bus

Date: 2023-01-10

Status

Accepted

Related to ADR-0005: Use standard NATS clients if available

Amended by ADR-0006: NATS message format

Context

For Telestion to be truly extensible and modular, various aspects of the application might have to be written in different programming languages (e.g., scientists might prefer to write specific parts of the application in Python).

A vendor lock in (for example into Vert.x) is therefore not advised. There are several solutions for message buses that are not vendors or library-specific. They include (apart from many others that were not deeply looked into for several reasons):

Each of the solutions have several advantages and disadvantages. The most important factors for the project are as follows:

From the various considered options, NATS seems to fit our requirements the best.

Of special note is also the queue groups feature that has the potential to make clustering/scaling (even in a broadcast pattern) easy, as demonstrated in the following video (beginning at 5:25):

NATS demo video

It also offers an extensive authentication/authorization feature, subject hierarchies, and more.

Also, according to nats.io, it’s used by many big companies, such as PayPal, AT&T, Netlify, Siemens, and others, and supports clients for many different languages.

Decision

We will use NATS as the distributed message bus/message broker for Telestion.

We will use NATS’ integrated authentication and authorization features to handle authentication and authorization for Ground Station operators to have a single source of truth for authentication and authorization.

We will no longer feature an event bus bridge, but instead connect clients directly to the NATS server.

Consequences

We will no longer be able to use Vert.x’ EventBus for communication between components. Instead, we will have to use NATS’ client libraries for the respective programming languages.

Authentication and authorization will be handled by NATS’ built-in features. Authorization will therefore be exclusively up to the message addresses.

We will have to deploy and maintain a NATS cluster for the project.

We will have to implement a NATS client for the Telestion Client. This will be based on NATS SDKs but feature an easier API for the Telestion Client.

We will have to implement a NATS client for the Telestion Application. This will be based on NATS SDKs but feature an easier API for the Telestion Application.

  1. RabbitMQ homepage 

  2. Apache Kafka homepage 

  3. NATS homepage