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.

https://d33wubrfki0l68.cloudfront.net/5992fd71838685f57f403365345a1d5c8e044551/a7e62/_images/architecture.png

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.

Containers

When using docker-compose, most services are hosted in their own containers (see note under db). The containers started are specified in the services section of the docker-compose file and correspond to components in the diagram as described below:

Container Name Description Component in diagram
rasa-x Rasa X backend, UI and HTTP API Rasa X
rasa-production Rasa 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 UI Rasa Open Source
rasa-worker Rasa Open Source service used for background tasks such as training models Rasa Open Source
db

PostgreSQL database service

Note: The db container 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
rabbit Message broker used to transmit conversation events between rasa-production and rasa-x. Event Broker
redis Service acting as a persistence layer for tracker (conversation) locks Lock Store
nginx Reverse proxy used to reroute requests to the different services Nginx
app Custom action server; this service should be overwritten with your custom action server in docker-compose.override.yml Action Server