Architecture

Rasa X is built on a microservice architecture. There are three core services that are started when Rasa X is launched: Rasa X, the event service, and the database migration services. Other services that are required for a fully functioning installation can be started along with Rasa X (controlled by the Rasa X Helm Chart) or started separately and connected to Rasa X.

Services#

The diagram shows three main categories of services: The purple components are the main Rasa X Services, the blue components are Rasa Open Source servers, and the orange ones are third party services.

Rasa Open Source and Rasa X have independent databases. Conversation events data flows from Rasa Open Source servers to Rasa X via the event broker, and Rasa X in turn makes API calls to Rasa Open Source servers to train, run models and trigger conversation events.

Rasa X Services#

The purple boxes represent the three Rasa X services. These are the main required services to run Rasa X, in addition to the event broker and SQL DB. All three services run the Rasa X image, and all three should run the same version of that image. All three services can be run as one deployment; running them separately is advised for scalability. The diagram above assumes each service is running separately.

• The Event Service consumes conversation events data from the events broker and stores it in the Rasa X database.
• The DB Migration Service service ensures the database schema is up to date for the currently running version of Rasa X.
• The Rasa X service runs the Rasa X backend and frontend. Rasa X backend service stores and retrieves conversation data, training data and metadata, like conversation tags and flagged messages, in the Rasa X database. The Rasa X frontend makes API calls to the Rasa X backend. It provides a user interface for interacting with conversation and training data.

Third Party Services#

Required services:

• The Event Broker streams events from Rasa Open Source servers to the event service.
• The SQL DB stores conversation events, training data and metadata for Rasa X. Note that this is an entirely separate database from the Rasa Open Source tracker store, although the same PostgreSQL server can be used to serve both the Rasa X SQL DB and the tracker store if desired.
• The DB Cache is a Redis instance that acts as a cache for database queries to improve performance on large datasets.

Rasa Open Source Services#

Rasa Open Source can run completely independently of Rasa X. Rasa X on the other hand depends on the Rasa Open Source service for handling conversation data, model training and running. For details on the architecture of Rasa Open Source, please see the Rasa Open Source docs.

In order for Rasa X to display conversations held with a Rasa Open Source server, the Rasa Open Source server publishes conversation events to the same event broker from which the Rasa X event service consumes. Rasa X can also act as a model server and input channel for a Rasa Open Source server. See Connecting Rasa Open Source to Rasa X for details about the connection types.

The "Assistant in Production" server represents a Rasa Open Source server that only streams its events to Rasa X. It does not act as a deployment environment for Rasa X and Rasa X will not send training requests to it. The Rasa X Helm chart cannot spin up this deployment; it is expected that the server be deployed separately and then connected via the event broker.

Rasa X sends input requests to from the built-in channels (Interactive Learning/Share your Bot)to the "Interaction Environement/rasa-production" deployment environment. The interaction environment also publishes conversation events to the event broker. Bot responses in Interactive Learning/Share your Bot are returned via the event broker, and not directly from the REST response to the input. This means that without a correctly configured event broker, you will not see responses in Rasa X channels.

Rasa X sends training and NLU cross-validation requests to the "Training Environment/rasa-worker" deployment environment. The training environment posts the results of training and evaluation back to Rasa X. This environment is not used for having conversations with the bot and therefore does not publish conversation events to the event broker.

In theory, you could use a single Rasa Open Source server for one or more of the above purposes. It is recommended to follow the architecture above to avoid training or development activities impacting an in-production assistant.

The app deployment is for a custom action server for a Rasa Open Source server. Although it can be started by the Rasa X Helm chart, it is not part of Rasa X's architecture, but rather of Rasa Open Source's. It is therefore not shown in the diagram.