Server architecture reference#
The following diagrams detail suggested architecture configurations of high availability Mattermost deployments at different scales. Hardware and infrastructure requirements will vary significantly based on usage and policies. See the scaling for enterprise documentation for reference architecture guidance at scale, including hardware and infrastructure requirements.
Reference architectures#
High availability in Mattermost consists of running redundant Mattermost application servers, redundant database servers, and redundant load balancers so that failure of any one of these components does not interrupt operation of the system. Upon failure of one component, the remaining application servers, database servers, and load balancers must be sized and configured to carry the full load of the system. If this requirement is not met, an outage of one component can result in an overload of the remaining components, causing a complete system outage.
You can apply most configuration changes and dot release security updates without interrupting service, provided that you update the system components in the correct sequence. Changes to configuration settings that require a server restart, and server version upgrades that involve a change to the database schema, require a short period of downtime. Downtime for a server restart is around 5 seconds. For a database schema update, downtime can be up to 30 seconds.
Designed for scale#
Mattermost is designed to be able to handle a large number of concurrent users, and the architecture can be scaled up or down as needed. The architecture is also designed to be flexible, allowing for the addition of new components or services as needed. The following diagrams show the recommended architecture for Mattermost deployments at 5,000, 10,000, 25,000, and 50,000 users. The diagrams are organized by user count and include a general diagram and AWS and Azure versions of each diagram. See the scaling for enterprise documentation for more information on scaling Mattermost deployments.
Each generalized diagram represents a full High Availability deployment across all critical components. The proxy, database, file storage, and Elasticsearch layers can be replaced by cloud services.
Each AWS diagram represents a full High Availability deployment on Amazon Web Services making full use of the available services.
Each Azure diagram represents a full High Availability deployment on Microsoft Azure making full use of the available services.
Push proxy can be replaced by the Mattermost hosted push notification service.
General

AWS

Azure

General

AWS

Azure

General

AWS

Azure

AWS

Azure

Database with Virtual IPs#
We recommend the following configuration for Highly-Available databases through virtual IPs.
