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).
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.
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 Name | Container Name | Description | Component in diagram |
|---|---|---|---|
rasa-x event-service | rasa-x | Rasa X backend, UI and HTTP API | Rasa X |
rasa-production | 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-worker | Rasa Open Source service used for background tasks such as training models | Rasa Open Source |
postgresql | db | PostgreSQL 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 |
rabbit | rabbit | Message broker used to transmit conversation events between rasa-production and rasa-x. | Event Broker |
redis | redis | Service acting as a persistence layer for tracker (conversation) locks, and a multi-purpose in-memory cache. | Lock Store |
nginx | nginx | Reverse proxy used to reroute requests to the different services | Nginx |
app | app | Custom action server | Action Server |