Chat Application Architecture

1
INDEX

Contents
INDEX ......................................................................................................................................................................... 2
1. OBJECTIVE ......................................................................................................................................................... 2
2. REQUIREMENT SPECIFICATIONS ........................................................................................................................ 2
2.1 ACTORS AND USE CASE ........................................................................................................................................... 2
2.1.1 UC01- User login ....................................................................................................................................... 2
2.1.2 UC02 – Ask or Post queries ....................................................................................................................... 3
2.1.3 UC03 – Save contents ............................................................................................................................... 3
2.1.4 UC04 – Authentication Services ................................................................................................................ 3
2.1.5 UC05 – Logout .......................................................................................................................................... 3
3. CONCEPTUAL MODEL: ....................................................................................................................................... 3
4. ARCHITECTURE DIAGRAM ................................................................................................................................. 5
5. QUALITY ATTRIBUTES & LIST OF ARCHITECTURALLY SIGNIFICANT REQUIREMENTS........................................... 6
6. ARCHITECTURE PATTERNS ................................................................................................................................. 7
7. FAILURE AND IMPROVEMENTS.......................................................................................................................... 7
7.1 FAILURES ..................................................................................................................................................................... 7
7.2 IMPROVEMENTS ............................................................................................................................................................ 7

1. Objective
To build a chat application architecture that supports interaction among students and between
teachers & students.

2. Requirement Specifications
There is a requirement in an educational institution to establish a communication system between
students and subject teachers. The communication application is required to be a chat application
that will enable students to discuss, post queries and teachers can respond to queries as well post
questions/quizzes/assignments or it’s related information. This application can be used on either
computers or mobile devices like tab or mobile phones and should be available always when
needed. The application is supposed to work 24x7 during institutional working days without fail.

2.1 Actors and Use Case

2.1.1 UC01- User login

Actors: Users, Authentication Services
Use Case: A user can be either Student/teacher or Administrator of the system. Chat
system shall have login feature for all users and for accessing the system, a user has to
input login credentials, comprising of a User ID and password. While creating profile of
Student and Teacher, the system shall have personal details of the user. Teacher shall
have admin rights to make changes in data stored in the system.

2
 2.1.2 UC02 – Ask or Post queries
Actors: Users (Teachers, Students)
Use Case: Chat application should be able to get/post queries received by users. Techers
should be able to resolve queries of students. Students should be able to communicate
with other users.

2.1.3 UC03 – Save contents

Actors: Chat Application, Database
Use Case: Chat application should be able to save chats to database. Also it should track
a log of chat communication and save to database.

2.1.4 UC04 – Authentication Services

Actors: Users, Database, Authentication services
Use Case: Chat application should be able to save chats to database. Also it should track
a log of chat communication and save to database.

2.1.5 UC05 – Logout

Actors: Users, Authentication services, Database
Use Case: Chat application should be able to logout users and save the contents to
database before logging out.

Fig 1: Use case diagram

3. Conceptual Model:
The basic architecture is composed by a Back-end with Python and Django, using PostgreSQL
database and ReactJS and Redux on the Front-end. The simple chat system is without real-time

3
operations, in other words, just a CRUD of messages with simple database modeling with only two
tables: Chat and Message. The below diagram is for simple chat application architecture.

Fig 2: Simple Architecture of chat application

The above simple architecture of chat application is client and server architecture without real-time
implementation. The simple chat app does not provide auto refresh of the chat responses. Therefore
for better user experience there is need to introduce the real-time refresh of the chats. The
synchronization of chat application will make better user experience. The below diagram shows
modified chat application with auto refresh feature:

Fig 3- Real time chat system

4
 4. Architecture Diagram

Fig 4: Application Architecture

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, friends’ invitation,
downloading sticker packs, etc. The Chat App (the chat client part) communicates 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 communicates with the Chat WebSocket Server via the Chat WebSocket Client
Library. This connection is open two ways; that means users don’t 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's split into three separate root components:

 Chat Client Engine handles all of the communication 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.

5
  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.

5. Quality Attributes & list of architecturally significant requirements

The chat system in consideration should be able to meet the requirement of institution. Based on
various discussions with (QAW), reading the requirement documents etc. lead to refining of the
quality attributes. These quality attributes define the qualities of the chat application functionality
like how should they behave or how fast to respond or how much they can scale in terms of
deployment etc. There are below mentioned quality attributes and their associated architecturally
significant requirements:

Quality Refinement
Architecturally Significant Requirements
Attribute Attribute
1. Chat system should be able to deliver and provide messages in
1. Transaction real-time without delay not permitted more than 0.3 sec. (H, M)
response time 2. The system should be able to support multiple simultaneous user
Performance 2. Throughput connections (150) at peak load. (H,H)
1. A functionality upgrade into UI completes without introduction
of delays/lags. (M,M)
1. Normal 2. Users can request help or access help documents and system
operations provides helps within 5 second. (M,L)
2. Proficiency End users should be able to understand the application use within 1
Usability training day. (M,L)
1. The institution introduces new features for users and
1. User-defined configuration team should be able to introduce within a working
Configurability changes day. (M,L)
1. A maintainer encounters search- and response-time deficiencies,
fixes the bug, and distributes the bug fix with no more than 3
1. Routine changes person-days of effort. (H,M)
2. Upgrades to 2. The database (Chat content media/storage server) vendor
commercial releases a new version that must be installed in less than 3 person-
Maintainability components weeks. (H,M)
1. Adding new 1. Adding a quiz module that provides details of quiz and result to
Extensibility product individuals, requires 2 persons a month time. (M,M)
1. Users should only be able to see their chats but NOT for other
users’ session. (H,H)
1. Confidentiality 2. The system resists unauthorized intrusion and reports the
Security 2. Integrity intrusion attempt to authorities within 90 seconds.(H,H)

1. Service 1. A components REST API change should be able to get implement

Modifiability Integration without affecting another component APIs within a week. (H,M)
1. The database vendor releases new software, which is
hot-swapped into place, with no downtime. (H,L)
The system supports 24/7 web-based or mobile account access by
Availability 1. No downtime Users.(H,M)

6
 6. Architecture Patterns
There are below mentioned Architecture patterns used for the chat application:
1. Client-Server pattern – The idea to have this pattern is to support Separation of concerns,
Synchronous Communication and Flexible Deployment.

2. Publish & Subscribe pattern – Webserver and Micro services server.

3. Service Oriented pattern – Consuming REST API of authentication provider for user login.
4. Component based pattern – Chat media storage from vendor like Amazon, Authentication
provider etc.
The architecture of the herein chat application is Client – Server pattern because only storage and
authentication services are provided by vendors.

7. Failure and Improvements

7.1 Failures
The chat application may encounter below failures:
1. Performance bottleneck,
2. Component integration failure,
3. Migration issue

7.2 Improvements
The above failures can be addressed by following:
1. 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. To achieve this
we will introduce scalability within the architecture by introducing load balanced cluster of
servers or application servers. This will reduce the overhead performance on single server.

2. Integration: Independent components can be easily integrated with the chat

application’s services upon request. For example, if the institution wants user files
(quizzes/assignments) to be stored in their SharePoint content database, integrate the
SharePoint with the Chat Media Storage without having to change the entire architecture.
To achieve this the individual components will be developed to have a loosely coupled
interface but with high cohesion.

3. Customization and migration: All the architecture components can easily be adjusted
to the institution’s needs. For example, they can be powered by different services: the Chat
WebSocket Server can be built on PubNub, Twilio, or Firebase, while Chat Media Storage
can be powered by Cloudinary or Amazon S3. Or will build any of the components entirely
from scratch if it is needed to perform specific tasks.