Architecture of live

chat tool
1 Chat Architecture: How We Approach It
A chat consists of two major parts:

 Chat App or client part, which is a desktop, web, or smartphone chat

application.
 Chat Server Engine or server part, which is a pool of external servers
responsible for the chat operation. This is the place where all the chat magic
happens.

Both parts contain various components that commuCustomer ate to each other and
bring the chat into action.

Chat Server Engine is a core of the chat architecture that handles message delivery
and dispatch. In our version of chat architecture, it includes the following
components:
  Chat REST API handles the tasks that are not connected directly to message
dispatch and delivery, such as user authentication, changing of user settings,
friend's invitation, downloading sticker packs, etc. The Chat App (the chat
client part) commuCustomer ates with the Chat REST API via the Chat REST
API Client Library.
 Chat WebSocket Server is responsible for transmitting messages between
users. The Chat App commuCustomer ates with the Chat WebSocket Server
via the Chat WebSocket Client Library. This connection is open two ways;
that means users do not have to make requests to the server if there are any
messages for them; they just get them right away.
 Chat Media Storage Server is a pool of servers responsible for storing user
media files. The files are uploaded to them via the Chat Media Storage
Client Library.

Chat App is the other major part of the chat architecture, the one that users directly
interact with. It is split into three separate root components:

 Chat Client Engine handles all of the commuCustomer ation with the Chat
Server Engine via its internal components: Chat REST API Client Library,
Chat WebSocket Client Library and Chat Media Storage Client Library. It also
comprises the Chat Push Message Handler that deals with push
notifications.
 Chat UI displays data to users via its widgets: Chat Contact List UI, Chat
Dialog UI, Chat Push Message Widget—extension for mobile apps that
allow for replying to messages without opening the app and Chat Internal
Notification Widget—a widget that pops up at the top of the screen while the
user is chatting in a dialog and notifies about the incoming message in
another dialog.
 Chat Device Storage is an internal database (read: your device storage),
which stores messages and files so that users can access them offline. Its
internal component, Chat Media Cache, gets media files from the Chat Media
Storage and stores them on the device so that the user can access them
anytime without having to reach the Chat Media Storage every time.

What Are The Benefits Of Our Approach?

Separation of components is at the core of our chat architecture. All the services that
the architecture comprises are independent from each other. Why? It is beneficial
from many perspectives:

 Reusability. When the chat components are designed separately, they can
be easily reused in other projects.
 Scalability. Each architecture component is a potential bottleneck when a
project grows bigger and begins to serve a larger audience. The advantage of
independent components is that they can be scaled separately without
affecting the entire architecture.
 Integration. Independent components can be easily integrated with the
customer’s services upon request. For example, if the customer wants user
files to be stored in their CRM, you can integrate the CRM with the Chat
Media Storage without having to change the entire architecture.
  Customization and migration. All the architecture components can easily be
adjusted to the customer’s needs. For example, they can be powered by
different services: the Chat WebSocket Server can be built on PubNub, Twilio,
or Firebase, while Cloud nary or Amazon S3 can power Chat Media Storage.
Alternatively, you can build any of the components entirely from scratch if you
need them to perform specific tasks.

The same is true for migration. If you want to migrate one component to another
service, you can do so without disturbing the rest of the components. We have seen
it ourselves when we migrated one of our products, Famlicious, from one service to
another.

The technology stack:

 node.js + Socket.io + Redis pub/sub:

 XMPP server like Openfire
 RabbitMQ

What made us build a new Chat Service using Micro-service

?Architecture

 We wanted to build a service which could be easily integrated within

the applications.

 Different applications should be supported form single deployed

service.

 The service should support a large amount of traffic, delivering the

data in real-time with data integrity.

 We wanted to store all the data on the premises for security

reasons.

 The service should be lightweight, cost-effective which could be

easily scaled up or down depending on the traffic.

 The service should easily customized to support different features

for the different application.

1.1.1. Technology Stack

 NodeJS (v8.11.0 LTS): an event-driven, non-blocking I/O model

that makes it lightweight and efficient, perfect for data-intensive real-time
applications that run across distributed devices.
 Socket.io (v2.1.1): enables real-time, bidirectional and event-
based communication. It works on every platform, browser or device,
focusing equally on reliability and speed.
 Redis (v4.0): in-memory data structure store, used as a database,
cache and message broker.
 Sequelize (v 4.41.2): a promise-based ORM for Node.js. It
supports the dialects PostgreSQL, MySQL, SQLite, and MSSQL and features
solid transaction support, relations, read replication and more.
 Docker (v18.09): an open platform for developers and sysadmins
to build, ship, manage, secure and run distributed applications, whether
on laptops, data centre VMs, or the cloud without the fear of technology or
infrastructure lock-in.
 EC2 Instance: provides different instance types to enable you to
choose the CPU, memory, storage, and networking capacity that you need
to run your applications.
 ElastiCache: offers fully managed Redis and Memcached.
Seamlessly deploy, run, and scale popular open source compatible in-
memory data stores. Build data-intensive apps or improve the
performance of your existing apps by retrieving data from high
throughput and low latency in-memory data stores.
 Application Load Balancer: serves as the single point of contact
for clients. The load balancer distributes incoming application traffic
across multiple targets, such as EC2 instances, in multiple Availability
Zones. This increases the availability of your application.
 Amazon Relational Database Service (Amazon RDS): makes it
easy to set up, operate, and scale a relational database in the cloud. It
provides cost-efficient and resizable capacity while automating time-
consuming administration tasks such as hardware provisioning, database
setup, patching and backups. 

1.1.2. Architecture

After lots of research and studying the architecture of

Applications like WhatsApp and Facebook, we came up with the
-following Architecture
 Architecture Diagram

1.1.3. Components in the Architecture:

 Clients: Any clients supporting Socket.io clients.

 EC2 Instances: Used for the deployment of the Chat service,
irrespective to any operating system since docker is used. Each chat
service installed on the instance is completely independent of the other
instances.
 AWS Application Load Balancer: It is a single point where all the
clients get connected with the sticky session. ALB distributes the load to
the EC2 instances and redirects the load if any EC2 instance fails to
respond.
 RDS(Relational Database Service): Any relational database can
be used to persist chat related data. Sequelize as an ORM help to use any
relational database.
 ElastiCache: Used as the Redis for the in-memory cache and
message broker service. Message broker service is used to transfer data
between two or more Chat services.

1.1.4. Message Delivery

Data Flow Diagram

 From the above flow, we were able to achieve real-time messaging using
each component efficiently. For example, not each and every message
needs to be published on the Redis. If the recipient of the message is
connected to the same chat server, there is no need to emit it to the all
.the servers. The message could be directly sent to the respective clients
1.1.5. Data store on ElastiCache

Using the ElastiCache we could avoid database queries.

ElastiCache provides high throughput and low latency in-memory
data stores. On the ElastiCache we are maintaining two maps
Users and Groups

When a client gets connected to the Chat server the User map is
updated, having the entry of the username, public name, server’s
name, and status. In this map, we store client’s minimal
.information which needs to be fetched frequently

In the Group Map, we store all the group with their members.
While sending a message to a group, we could fetch the recipient
.of the messages

1.1.6. Database Store

We are storing data in the database in an asynchronous way, avoiding any

.delay in the message delivery
 Peer Conversation: For every new peer, when connected, a new
entry is made on the storage. All the messages sent between two users
would have the same conversation id.
 Messages: The messages which need to be persisted are stored
here. It is common to the peer conversation and group conversation.
 Pending: All the messages links/ids are stored here, irrespective to
the type of conversation. When a user comes online, all the messages
from this storage is delivered to the user and then removed from it.
 Group Conversation: Stores group related information and has a
relationship with the Messages and Group members.
 Group Members: Stores members of the group and their roles in
the group.

2 Hawsabah live chat integration Guideline:

To integrate the live chat tool to your Website and mobile app, you should consider
the following:

Stage One embed code into your website

1. Hawsabah to send embedded code (iframe) to CUSTOMER website tech

Customer al team considering the security risks factors,

 Prerequisites from CUSTOMER - to send a whitelist of accepted domains

 Our backend code will include a white list include accepted domain list
through
 Hawsabah use Content-Security-Policy (CSP): frame-ancestors directive
specifies valid parents that may embed a page
using <frame>, <iframe>, <object>, <embed>, or <applet>. For all
browsers except Internet explorer, We will use X-Frame-Options
 Once the embedded iframe is added with a white list domains, the chat
box will be available for the beneficiaries to make a conversation

Stage two when user starts the chat:

 Consider only anonymous user conversation (beneficiary)

 Use captcha as a part of the user info "Name, mobile, email" to prevent
anonymous attacks.
 The beneficiary to start the chat
 In backend with each request, we will generate the token Include a CSRF
token within relevant requests. The token will be:

o Unpredictable with high entropy, as for session tokens in general.

o Tied to the user's session.
o Strictly validated in every case before the relevant action is executed.

 The operator will receive the conversation request, and send answer to the
customer (the system will generate a CSRF token for the operator)
 Unpredictable with high entropy, as for session tokens in general.
 Tied to the user's session.
 Strictly validated in every case before the relevant action is
executed.