notice

This is documentation for Rasa X Documentation v1.0.x, which is no longer actively maintained.
For up-to-date documentation, see the latest version (1.1.x).

Version: 1.0.x

Architecture

Rasa X is built on a microservice architecture. The diagram below provides a high-level overview of the services started when Rasa X is launched and their interaction with each other.

image

Services

The diagram shows two main categories of services; the blue components relate to Rasa Open Source, and the purple ones relate to Rasa X. Rasa Open Source and Rasa X have independent databases. Conversation events data flows from Rasa Open Source to Rasa X via the event broker, and Rasa X in turn makes API calls to Rasa Open Source to train, run models and trigger conversation events.

Rasa X Services

Within the Rasa X service, the event service consumes conversation events data from the events broker and stores it in the Rasa X database (SQL DB). The Rasa X backend also stores training data and metadata, like conversation tags and flagged messages, in the SQL DB. The Rasa X UI can be used from a web browser, it works by making API calls to the Rasa X backend. API calls can also be made directly to the backend, without the need of using the UI.

Rasa Open Source Services

The Rasa Open Source source service trains and runs NLU and dialogue models. When a conversation is being handled by a model, it adds events to a conversation tracker. It also makes API calls to the action server to run custom actions. Conversation trackers are stored in the tracker store, which can be any kind of database or an in-memory store. If an event broker is configured, events that are stored in the tracker store are published to it as well. The lock store ensures that, given multiple Rasa Open Source nodes, only one node can work on a single conversation tracker at a time.

It should be clear from this description that 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.

Deployments/Containers

When using the Helm Chart, the components in the diagram correspond to deployments and are specified in values.yml.

When using Docker Compose, the components in the diagram correspond to containers, which are specified in the services section of docker-compose.yml.

Most services are hosted in their own containers/deployments (see note under db/postgresql and rasa-x).

Deployment NameContainer NameDescriptionComponent in diagram
rasa-x event-servicerasa-xRasa X backend, UI and HTTP APIRasa X
rasa-productionrasa-productionRasa Open Source service running a trained model, used for parsing intent messages and predicting actions in conversations with user over the input channel or Rasa X UIRasa Open Source
rasa-workerrasa-workerRasa Open Source service used for background tasks such as training modelsRasa Open Source
postgresqldbPostgreSQL database service Note: The db container/postgresql deployment by default runs both the Rasa X SQL DB and the Tracker Store. However, these two databases are are separate and could also be run in separate containers.SQL DB & Tracker Store
rabbitrabbitMessage broker used to transmit conversation events between rasa-production and rasa-x.Event Broker
redisredisService acting as a persistence layer for tracker (conversation) locks, and a multi-purpose in-memory cache.Lock Store
nginxnginxReverse proxy used to reroute requests to the different servicesNginx
appappCustom action serverAction Server