Architecture

You are viewing documentation for a legacy Rasa product. If you want to get started building assistants with Rasa please check out our latest documentation here.

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

Services

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

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

Rasa Enterprise Services

The purple boxes represent the three Rasa Enterprise services. These are the main required services to run Rasa Enterprise, in addition to the event broker and SQL DB. All three services run the Rasa Enterprise 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 Enterprise database.
• The DB Migration Service ensures the database schema is up to date for the currently running version of Rasa Enterprise.
• The Rasa Enterprise service runs the Rasa Enterprise backend and frontend. Rasa Enterprise backend service stores and retrieves conversation data, training data, and metadata, like conversation tags and flagged messages, in the Rasa Enterprise database. The Rasa Enterprise frontend makes API calls to the Rasa Enterprise 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 Enterprise. 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 Enterprise 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

Support for deploying Rasa Open Source servers in the Rasa Enterprise Helm chart will be dropped in the future.

Please use the Rasa Helm chart to deploy Rasa Open Source and see Connecting Rasa Open Source to Rasa Enterprise for connection information.

Rasa Open Source can run completely independently of Rasa Enterprise. Rasa Enterprise 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 Enterprise 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 Enterprise event service consumes. Rasa Enterprise can also act as a model server and input channel for a Rasa Open Source server. See Connecting Rasa Open Source to Rasa Enterprise for details about the connection types.

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

Rasa Enterprise sends input requests to from the built-in channels (Interactive Learning/Share your Bot) to the "Interaction Environment/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 Enterprise channels.

Rasa Enterprise 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 Enterprise. 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 Enterprise Helm chart, it is not part of Rasa Enterprise's architecture, but rather of Rasa Open Source's. It is therefore not shown in the diagram.