Hosted and On Premise Chat Solutions

Clustering Architecture

AstraChat utilizes an advanced two-tier clustering architecture consisting of a front-end application tier and a back-end data storage tier.

The front-end tier consists of "data-less" application servers that are typically virtualized Windows Servers running the AstraChat application services. The AstraChat clustering architecture enables any subscriber to connect to any application node to access their messaging services. Subscribers are not “tied” to any node or any group of nodes in the cluster. This architecture allows for virtually unlimited horizontal scale by adding application nodes as the load increases.

The back-end tier contains the data storage devices. a SQL Server cluster is used to store the subscriber database, the cluster configuration database, the chat database and the logging database.

Clustering Architecture

In this proposed clustering architecture for a hosted service three key component are used:

  1. Nodes running AstraChat services
  2. Database servers running a mirrored SQL Server Cluster.
  3. Load balancing switches

In this configuration the load balancers distribute incoming connections to the servers based on the traffic type and current service load. Incoming Chat connections are distributed evenly between the application nodes hosting the requested service. Fail-over from one node to another is automatic: in the event of a system failure, the load balancer removes the failed server from the group of systems that receive traffic.

Active directory Integration

An alternative to Active Directory integration is to have all the user email accounts hosted locally on the platform. This would mean the users would need to set up and maintain a separate password for their chat access which is not linked to their Active Directory domain account. This approach would remove the need for the domain integration described above, and ensure platform independence at the expense of a less integrated user experience.

Chat Message Flow

Chat connections are routed by the load balancers to an application server which is currently part of the chat cluster. The connections are defined as ‘sticky’ so a single user will always connect to the same node for the duration of their chat session.

Messages are received from clients using secured (TLS or SSL) XMPP (jabber) protocol. If the recipient of the service is not a local user the message is relayed internally to the recipient’s server and relayed to them. If the recipient of the message is local but not online the message is stored for delivery in the SQL database. If the recipient is local and currently online the message is relayed directly to the client.