Scaling Rocket.Chat with Microservices

In a monolithic deployment, Rocket.Chat runs as a single application process where all core components (WebSocket handling, authentication, presence, etc) operate together. This model is straightforward to deploy and manage at a small scale. However, as usage grows, resource contention becomes a concern. When one component experiences heavy load, it can impact the performance of the entire application.

In a microservices architecture, these core components are separated into independent services. Each service runs in its own container and can be scaled, updated, or restarted without affecting the others. For example, if WebSocket connections become a bottleneck, you can scale only the WebSocket service while leaving authentication, presence, and other services unchanged. This approach provides better resource isolation and more controlled scaling at larger workloads.

Rocket.Chat officially supports deploying microservices using Kubernetes with the official Helm chart. Direct Docker microservice deployment is not supported.

In this guide, you’ll learn:

When you should scale with microservices

Consider scaling up your workspace if:

You’re seeing performance degradation during peak usage.
You need high availability.
You want to scale individual bottlenecks (e.g., WebSocket connections) without scaling everything.

Key components of Rocket.Chat microservices

Rocket.Chat’s microservices architecture includes several components, each focused on a specific feature. These components work together to create a fully operational workspace.

Component	Description
authorization (`rocketchat/authorization-service`)	Manages role and permission validation, ensuring users only access what they’re authorized to.
accounts (`rocketchat/accounts-service`)	Handles user account management and login authentication.
presence (`rocketchat/presence-service`)	Tracks and manages user presence status across the workspace.
ddp-streamer (`rocketchat/ddp-streamer-service`)	Handles all WebSocket connections using the Distributed Data Protocol (DDP).
nats (`docker.io/nats`)	A high-performance messaging system that acts as a central message bus for all microservices. Instead of services communicating directly with each other, requests are routed through NATS, which forwards them to the correct destination. To learn more about NATS, see the official documentation.
The central Rocket.Chat monolith (`rocketchat/rocket.chat`)	In a microservice deployment, the features of each individual service are disabled within the central monolith. This allows the dedicated microservice to take over its respective function.

Rocket.Chat's microservices deployment is illustrated in the diagram below.

Diagram of the Rocket.Chat microservices deployment

Scaling your Rocket.Chat workspace with microservices

This guide explains how to scale an existing Rocket.Chat microservices deployment that is already running with a single replica.

If you have not yet deployed Rocket.Chat on Kubernetes, start with the Deploy with Kubernetes guide.

To scale your deployment, you'll need to modify the values.yaml file and then upgrade your Rocket.Chat deployment using Helm. For the other parameters you can set, see Configure your deployment.

Step 1: Configure replicas

A replica is a running copy of a service. Running multiple replicas means that if one copy fails or becomes overloaded, the others continue to serve traffic.

To configure replicas, choose between setting a global count for all services or specifying a count for each service individually.

Set a global replica count

Set replica for individual services

Setting a global replica count is the quickest approach and works well if you want uniform scaling across your deployment. It means setting the same number of replicas for all microservices at once.

To scale all services to the same number of replicas, modify the replicaCount in your values.yaml file. For example, to set two replicas for all services:

microservices:
  enabled: true  # Enable microservices
replicaCount: 2

For more granular control, you can specify a unique number of replicas for each service. This is useful if certain services need to handle more load than others.

Locate the microservices section in the values.yaml file, remove replicaCount and specify replicas for each service. NATS replicas are set in the top-level nats section:

microservices:
  enabled: true
  presence:
    replicas: 2
  ddpStreamer:
    replicas: 2
  account:
    replicas: 2
  authorization:
    replicas: 2
nats:
  cluster:
    replicas: 2

For the ddp-streamer, plan 1 pod per 500 concurrent users.
Remove replicaCount when you define replicas for each service.

Step 2: Apply the changes

After saving your changes in values.yaml, upgrade your deployment to apply them:
```
helm upgrade rocketchat -f values.yaml rocketchat/rocketchat -n rocketchat
```
Helm returns the release details with STATUS: deployed.
Verify the new pods:
```
kubectl get pods -n rocketchat
```
If you set a global replica count, the list shows that number of pods for Rocket.Chat and for each microservice, all with the status Running.
If you set replicas for individual services, each service shows the number of pods you configured for it.
Confirm the number of running instances in the workspace:
1. Go to Manage > Workspace.
2. Under Deployment, click Instances.
A list of all active Rocket.Chat instances is displayed.