SCHOOL OF COMPUTER SCIENCES

SEMESTER I 2022/2023

CSE341 - SOFTWARE ARCHITECTURE AND DESIGN

ASSIGNMENT I: CASE STUDY

REDBUS WEBSITE: ARCHITECTURE AND DESIGN REPORT

LECTURER: ASSOCIATE PROFESSOR DR. ZURINAHNI ZAINOL

PREPARED BY:

Name Matric No. Email Role

Nur Ezzaty Binti Mohd Nordin 154214 [email protected] ‐ Introduction

sm.my ‐ Module structure

Norsyasya Binti Mohd Nazri 153777 nmnorsyasya64@stude - 4 + 1 view

nt.usm.my - Constraint
- Size and performance

Nur Syahirah Binti Norazman 150232 syahirahnorazman@stu ‐ Component and

dent.usm.my connector structure
‐ Quality

Siti Nor Farah bt Hussin 150217 sitinorfarah307@studen ‐ Allocation structure

t.usm.my ‐ Size and performance

SUBMISSION DATE: 2 DECEMBER 2022

TABLE OF CONTENT
1.0 EXECUTIVE SUMMARY ....................................................................................................... 3
2.0 INTRODUCTION .................................................................................................................... 4
2.1 Purpose ................................................................................................................................ 6
2.2 Scope .................................................................................................................................... 7
2.3 Definitions, acronyms, and abbreviations .............................................................................. 8
3.0 SOFTWARE ARCHITECTURE .............................................................................................. 9
3.1 Module structure .................................................................................................................. 9
3.1.1 Decomposition style ......................................................................................................... 9
3.1.2 Layered style ................................................................................................................. 10
3.2 Component and connector structure ................................................................................... 11
3.3 Allocation structure ............................................................................................................ 12
4.0 4+1 ARCHITECTURAL VIEW ............................................................................................. 13
4.1 Logical view ........................................................................................................................ 13
4.1.1 Class Diagram ............................................................................................................... 13
4.1.2 Sequence Diagram ......................................................................................................... 14
4.2 Process view ........................................................................................................................ 15
4.2.1 Control Flow Charts ....................................................................................................... 15
4.2.2 Data Flow Charts ........................................................................................................... 16
4.3 Development view ................................................................................................................ 17
4.3.1 Component/ package diagram.......................................................................................... 17
4.4 Physical view ....................................................................................................................... 18
4.4.1 Deployment diagram ...................................................................................................... 18
4.5 Use Case view ...................................................................................................................... 19
5.0 CONSTRAINT ....................................................................................................................... 20
6.0 SIZE AND PERFORMANCE ................................................................................................ 21
7.0 QUALITY .............................................................................................................................. 24
7.1 Functionality ...................................................................................................................... 24
7.2 Reliability ........................................................................................................................... 26
7.3 Usability ............................................................................................................................. 29
7.4 Efficiency ............................................................................................................................ 31
8.0 REFERENCES ...................................................................................................................... 32

2
1.0 EXECUTIVE SUMMARY

redBus is a mobile or web application that was built by three engineers, they are Phanindra Sama,
Charan Padmaraju and Sudhakar Pasupunuri. These engineers had a develop an application that can provide
many services to its user. They are Bus Hire, Bus Ticket, rPool (bikepool and carpool), rYde, and redRail.
Howerver in this case study, we will be focusing more on the Bus Ticket system which allow the customer
to book bus ticket through physical or online purchase. There are so many software architectures involves
in redBus bus booking system. They are module structure, the component and connector structure, and the
allocation structure.

Moreover, the redBus system also contains 4+1 Architectural view. In this case study, we provide
a logic diagram which only consist of class diagram of the redBus system and the sequence diagram of the
transaction payment. Meanwhile, for process view we present only confirmation booking data flow charts
and data flow charts of the redBus system. Development view shows the component diagram of the redBus
booking system. Deployment diagram of the redBus is shown in the Physical view. Lastly, use case view
that show the interaction of the user and all other modules that exist in the redBus system.

There are so many constraints in the redBus system. The constraint that can be identified are the
lack of innovation and critical talent of the developer. Next the redBus application does not provide a direct
communication between the passenger and the bus driver. The developer also had a difficulty in maintaining
the payment and refund system. Lastly, redBus system acquire a large space of memory for a user to
experience excellent performance of the application.
The size and performance of the redBus system can be seen on the size of the database used to
accommodate a large amount of data of a large amount of user and the performance of the application can
be seen to the time taken for the search engine to response to the user request.

The quality of the redBus system is discussed based on four quality attributes which are
functionality, reliability, usability, and efficiency. Functionality highlights how the main features of the
redBus system are supposed to work for users. Reliability highlights how the system should be functional
in a specific environment for a period. Usability concerns how easy and effective the system should be for
users and lastly, efficiency is the performance of the redBus system. These quality attributes are also
reflected to user experience using the user reviews to know how far the system fulfill the existing quality
requirements.

3
2.0 INTRODUCTION

System architecture is a set of structures that involve the main components, the relationship
between the structures and how the system structures interact. Software systems are divided into two parts,
namely software architecture and software design. In Architecture, non-functional decisions are cast and
separated by the functional requirements. In design, functional requirements are fulfilled. Architecture
serves as the blueprint for the system. It provides an abstraction to manage system complexity and establish
communication and coordination mechanisms between components. In contrast, software design provides
a design plan that describes the elements of the system and how they fit together and work together to meet
the system's requirements [1]. In this project documentation, we will present the architectural view and the
software design of our software system, which is the redBus application.

The redBus app is a platform for booking bus tickets online, and it provides ticket booking facilities
through its website and iOS and Android mobile apps. Founded in August 2006 and headquartered in
Bangalore, the redBus app connects bus travelers with a network of more than 2000 bus operators [2][3]
across India, Malaysia, Indonesia, Singapore, Peru, and Colombia. It claims to have registered over 180
million trips [2] with a customer base of over 20 million.[2] In 2018, the company achieved a GMV of ₹50
billion (equivalent to ₹57 billion or US$710 million in 2020), with a 70% share in the Indian online bus
ticketing segment.[3].

In terms of industry, this company is categorized as domestic travel, and it is the first company to
establish an application to book bus tickets online in India. RedBus has the largest network of bus operators
on their list (350+ and growing), and the investors for globally recognized redBus are TiE-EAP
(Entrepreneurship Acceleration Program), Inventus, and Helicon ventures. In just a few years of their
journey, the three entrepreneurs increased their revenue to above $12M [4]. They also sell two cloud-based
software, BOSS and Seat Seller, to bus operators and travel agents.

4
 The redBus success story was founded by three key people Phanindra Sama, Charan Padmaraju
and Sudhakar Pasupunuri. The three engineers from BITS Pilani are the founders of the redBus. After their
graduation, they worked for MNCs in Bangalore. Phanindra Sama worked for STs Microelectronics and
Texas Instruments, Charan Padmaraju for Honeywell and Sudhakar Pasupunuri for IBM. Phanindra Sama
was the master brain in evolving redBus. He was the chief executive officer for redBus for eight years.
Next, the goal and objective of redBus are to ensure people do not have to leave their comfort zone to book
a ticket and to assist them in getting a ticket when they need it the most. In 2015, their goal was to achieve
annual revenue of INR 5 billion by 2015, focusing on core business, vertical integration, increasing service
portfolio and going global. With their efforts, they have successfully stepped onto the worldwide stage.

5
2.1 Purpose

This project report will discuss the architecture design for this redBus system application, including
the module structure, component and connection structure, and allocation structure. Each of these structures
offers a unique design perspective and system handling, and they are all valid and valuable. Our goal is to
build a good system that stakeholders can understand. In addition, we also want to achieve the requirements
stated during the documentation. If the architecture is poor, it will have a bad effect when implementing
the system, and it will show that the purpose of this project has failed in terms of attribute quality, and it
will cause difficulties in maintaining, deploying, and managing.

In addition, with the existence of this software architecture, it is easier for stakeholders to
communicate with each other. This is because it allows stakeholders to share and discuss matters related to
aspects of the project. Although each stakeholder has a different background, with this architectural design,
we can give them a little insight so that it is easy to understand, even if it is abstract.

Next, we aim to have a good software architecture to help implement and manage change. Changes
during the development of the system are hard to avoid. This is because the market, needs, costs, changes
in business strategy and technological progress can be the catalyst for changes in software requirements, so
it is imperative to build a good architecture design. We can also reuse this model if the system created by
redBus has similarities with the model that has been made. As a result, we can reuse the same model and
save time and costs.

Finally, the critical thing that needs to be there in the purpose of building this architectural design
is to make it easier for new members who have just joined the software development group to understand
the structure of the software that will be built, is being assembled or has been created. An unclear
architectural design can make it difficult for new members to understand the structure, and it will have a
negative impact on the group and the system. If they do not understand the structure, the software they build
will take a long time to complete or be overhauled. Then it will increase the cost and cause wasted time. In
conclusion, we must have a purpose in building software so that the goal can be achieved, and the
application can be used worldwide.

6
2.2 Scope

The diagram below shows a list of features or deliverables based on project requirements.

Figure 2.2.1: Main modules of redBus Bus Ticket Booking System

The bus schedule module will display each bus's travel schedule for the departure and return
destinations. Users can view the bus schedule and select a date and time to plan a trip to their destination.
Next is the reservation module, allowing users to buy tickets online using the redBus software application.
Users can choose the destination they want to go to and make a reservation on the redBus app. Then, after
making the reservation, the user will pay for the bus ticket that has been booked, and this function is under
the payment module. As for the ticket module, this module will display complete user information, bus
information, and travel information. This ticket can be used online or physically by printing the ticket.
Lastly, the maintenance module, this module aims to make it easier for redBus to maintain user information
as well as fleet management information. It aims to take care of this redBus software application to avoid
technical or security issues.

7
2.3 Definitions, acronyms, and abbreviations

Term Definition

MYR Malaysian Ringgit, which is the official currency, used in Malaysia.

SGD Singapore Dollar, which is the official currency, used in Singapore.

SQL Structured Query Language. A programming language used to manage

and perform operations on relational databases.

OLTP Online Transactional Processing. A data processing method that

performs transaction-focused tasks.

TTL Time To Live. A mechanism for data deletion after its expiry.

NLP Natural Language Processing. A branch of Artificial Intelligence that

can generate and control human language

8
3.0 SOFTWARE ARCHITECTURE

3.1 Module structure

3.1.1 Decomposition style

Figure 3.1.1.1: redBus Bus Ticket Booking System Decomposition Style

The diagram above is the redBus Bus Ticket Booking System, divided into subsystems. There are five
submodules: bus information system, reservation system, payment system, ticket system, and maintenance
system. The diagram above is one type of module view which is the decomposition style. Each module has
its function, and it has an is-a-relation.

9
3.1.2 Layered style

Figure 3.1.2.2: Stack style on how the redBus use WhatsApp too increase communication

Based on the figured above the allowed to use relationship can be observe by the geometric adjacency of
the structure. The upper layer can be considered as the Application Programming Interface (API) and the
second layer show the language used in the development of the system and the third layer show the various
type of Natural Language Programming (NLP). Lastly, the last layer is used to show the connection of the
databased to store a desired data.

10
3.2 Component and connector structure

The architectural diagram of component and connector view can be presented using Service-Oriented
Architecture Style (SOA) as shown as follows.

Figure 3.2.1 Component and connector structure of the redBus system in UML notation

Figure 3.2.1 illustrates the components, interfaces, and relationships between the Bus schedule, Booking,
Ticket, Payment, Travel, Report, and Maintenance. All modules except the Maintenance module are
provided with a user interface, represented by a ‘lollipop’ arrow because these modules need user
interaction while Maintenance only concerns the backend. All modules are connected to components
Security and Persistence with specific configuration of encryption and access control. Persistence
component is connected to the database because it concerns the data storing, in which the data remains in
the database even after the system shutdown.

11
3.3 Allocation structure

Figure 3.3.1 Allocation structure of the redBus system in development style

Figure 3.3.1 above shows the allocation structure for redBus application where the software elements in
the software architecture interact with non-software elements in the environment in which the software is
developed, deployed, and executed. Here the customers, customer services, operator and business team as
the non-software elements interacted with the rest software system.

12
4.0 4+1 ARCHITECTURAL VIEW

4.1 Logical view

4.1.1 Class Diagram

Figure 4.1.1.1: Class Diagram for redBus bus booking system.

Based on the diagram above, redBus, bus booking system have 6 class. They are interface class, customer
class, refund class, ticket class, booking counter class, and agent class. The class diagram shows the static
structure of the redBus system. Based on the diagram above, there is an interaction between all classes. The
first relation is the customer get a refund. The customer also can book one or many tickets. One or many
customers can be assigned to one or many agents. One or many customers can request a booking ticket. An
agent can book, one or many tickets.

13
4.1.2 Sequence Diagram

Figure 4.1.2: Payment sequence diagram for redBus.

The sequence diagram above shows the relationships between the Transaction system, payment service and
payment gateways, and the sequence in which the interaction are during the execution of a certain use case.
Based on the diagram above, they are categorized by redBus as EDNC, IDNC, and internal drops between
the payment and transaction systems (external drops between payment gateways and payment system).
Additional categories for EDNCs include SF (salesforce status check) and RECON (settlement sheet). In
this manner, redBus are kept up to date on the causes of errors and the efficiency of these dissimilar systems
in locating genuine reimbursements.

14
4.2 Process view

4.2.1 Control Flow Charts

Figure 4.2.1.1: User generated review control flowcharts for redBus.

The diagram above shows the flow of the how redBus generated the user review to the API system. The
user will provide the review that he/she has completed. In the process the system will perform a Tagging
and Random Forest Algo. The tagging is used to review the summary and filters, highlight the word that
related to the tags and act as a classifier for example punctuality, experience, staff, amenities and rest stop,
meanwhile the Random Forest Algo are used for classification and aggregation of data and handle some
data points that are missing.

15
4.2.2 Data Flow Charts

Figure 4.2.2.1: Data flowcharts for redBus.

Based on the figure above, it shows a pictorial picture of how data is transferred across system activities.
redBus have numerous layers, each of which is specialised to a particular process or data function. RedBus
uses a combination of SQL and NoSQL databases to handle many kinds of issues. Based on the diagram
above, redBus use Redshift, Google Big Query, Cassandra, Elastic Cache- Redis, Mongo DB and Couch
DB. Moreover, the data from the 3rd party integration with bus and hotel vendors connected to inventory
and Central application programming interface (API) which connected to the line of business.

16
4.3 Development view

4.3.1 Component/ package diagram

Figure 4.3.1.1: Bus ticket booking development diagram for redBus.

The arrangement of redBus system components and their interdependencies are depicted using component
diagrams. They offer a broad overview of the parts that make up a system. Based on the diagram there are
five component that is connected to the redBus bus ticket booking system, which is bus and vendor
information, booking module, ticket information, customer information, and bas route information. All
these components are connected to security and persistence component. Persistence components are
connected to the database of the redBus system.

17
4.4 Physical view

4.4.1 Deployment diagram

Figure 4.4.1.1: Deployment diagram of how the redBus system and the WhatsApp application system.

Based on the diagram above it displays the setup of run-time processing nodes and the components that
reside on them. It is used to represent the physical components of an object-oriented system and to simulate
a system's static deployment perspective. The customer will send a request to the redBus server, and the
request will be processed in the Natural Language Processing (NLP) and to the fulfillment workflow
module which connected to the databased. After the translation engine has translate the request to a specific
language, a response will be conveyed to the user.

18
4.5 Use Case view

Figure 4.5.1: Use case view for redBus.

The diagram above shows how the user of the system which is the traveler, travel agent and bus stop counter
incharge, interact with the system module in the redBus bus booking system. There are 13 module that exist
in the redBus system. They are book ticket online, cancel booking online, book via agent, cancel ticket via
agent, cancel ticket at counter, book at counter, online enquiry, fill details, receive money on cancellation,
cancel ticket, book ticket, make payment and update database.

19
5.0 CONSTRAINT

There are many constraints in the RedBus website application system. First and foremost, is lack
of innovation and critical talent. There is not much more one can do in the ticket sales industry online. It is
challenging to come up with new ideas in such a concise manner, making the RedBus’s system weakness.
particularly in technology & digital transformation sector. Considering advancements in artificial
intelligence (AI) and machine learning, Bus redBus is striving to restructure procedures. Thus, to find a
developer that are creative and critical thinking are not that easy. Moreover, the developer needs to find an
innovation to make the redBus web application system look more outstanding compared to other bus
booking website application system. It is important to come up with something new as all the other
competitors are providing the same services and offer to attract the attention of the user.

Next, redBus application does not provide direct communication between the passenger and the
bus driver. The details of the bus and the bus driver are completely unknown to the passenger. This can
cause a difficulty to the passenger incase if there are any emergency happening towards the passenger that
can cause the passenger to arrive at the bus station a little bit late and there is an issue in mix up tickets or
arrangements of seat, the passengers are not able to communicate to the bus operator regarding the issue
that they faced.

After that, the developer of the redBus system had a difficulty in maintaining the payment and
refund system. redBus' payment system manages the transfer of payment information to and from several
internal systems and external payment gateways. All systems must be brought into an agreement with an
order's ultimate status. How to send and receive payment updates across such a diverse array of systems
while ensuring that the final updates are accurate, traceable, and indicative of future actions and
improvements are the issue faced by the developers.

Furthermore, in the future redBus acquire a large space of memory for a user to experience excellent
performance of the application, as the application would always be updated with a new version. For a
mobile phone that provided a small phone disk space, it is possible for the user to use and download the
application. In additional, redBus company faced a financial issue to upgrade and update the application
according to the user’s level of expectation. Moreover, redBus must identify the proper resource with the
necessary level of competence to target a new user group to deploy all the updated features, due to this the
cost of user acquisition would be higher.

20
6.0 SIZE AND PERFORMANCE

RedBus has over 18 million users from 24 states, more than 30,000 outlets along 80,000 routes,
and 2500 bus operators. Until now redBus has been known as the largest online bus ticket company. When
the day of celebrating a festival, there would be a lot of people who use redBus to book their ticket.
Regarding the high traffic of the system due to many users accessing the application or website application,
the developer should already know that the redBus server would be loaded with so many queries and
requests from the user. The database or the server would be able to handle such a high traffic that happens
simultaneously. Due to the high number of users. redBus has increased the size and scalability of their
databases by adding more and variety type of database to accommodate the large number of redBus users.
The databases that had been used by the redBus system are Redshift, Google Big Query, Cassandra, Elastic
Cache- Redis, Mongo DB and Couch DB. Each databased are specialized for a certain function such as
MongoDB are used to store the generic purpose document storage where in specific application logs,
configurations etc. and MySQL which used to store payment, transaction, user profile and every
information that relates to the transactional flow [14].

In cloud computing context, the redBus application performance can be measured by the real-world
performance and the availability of the applications. These two measurements are usually being used with
remote and cloud computing applications running through remote servers and servers over the Internet.
Through the service provided by the system management, it can indicate the level of performance and this
method has been used as the top monitored IT metrics. Application functionality and user responsiveness
are reflected in an app's performance. The performance of the redBus system can be seen through the actual
performance experienced by the end users of the redBus application. This measurement is often related to
response time either during normal loads or could be peak loads. In this case, it can be shown by response
time for the application to act upon the user’s action, the time taken or the response time for the system
takes to finish a specific amount of work such as searching or sorting data and lastly the load of system
which can be measured through the transactions volume for the application should be process such as pages
per second, transaction, and requests.

Based on the statistic, single search that is requested by the user, this is because the system will
spend time to search and compute over the same transformation before displaying the result to the user as
one search request contain multiple buses. When the user uses redBus, many buses are displayed to them
after a single search before they decide which one to book. The data is unlike the other, the information is
dynamically changing because it contains seat availability. It is preferable to evaluate system capacity in
21
terms of the total number of buses displayed to clients per second as opposed to the number of requests per
second. A single metric of RPS (request per second) would be inaccurate because each search request would
differ in terms of the quantity of search results (or buses). The performance of the search engine can be
evaluated by the time taken to response to the customer request. 60K buses per second would be displayed
by the system, the average latency is under 200 ms, 95th percentile search latency under 250 ms, 99th
percentile search latency under 340 ms and 99.9th percentile search latency under 490 ms. [15]

Figure 6.1, 6.2, 6.3: Customer positive reviews for redBus application

Some positive reviews had been given to the redBus application indicating the application performance
based on the response time and navigation.

22
 Figure 6.4, 6.5, 6.6: Customer negative reviews for redBus application
Some reviews also had been given to the redBus application regarding the application's low performance
based on the slow and inability to respond well including some glitches that happened during the
transaction.

23
7.0 QUALITY

This section will discuss and elaborate on the quality requirements of the redBus system and how the system
has fulfilled the requirements based on user experiences obtained online. The requirements will be classified
into four important quality attributes which are functionality, reliability, usability, and efficiency.

7.1 Functionality

This attribute reflects on how well the system does the work according to the defined requirements.
Functionality does not control the development of software architecture and is independent of any structure.
Despite that, this attribute is still important as requirements are assigned to the architectural elements to
fulfil this attribute [12].

In the case of the general redBus system, the features or modules performed by this system are the
bus booking system including online payment and bus information system, customer support system, rate
and review, bus tracking system, and rest stop schedule system. For the redBus system in Malaysia, there
is an additional feature which is a ferry booking system that covers three Southeast Asia countries,
Malaysia, Singapore, and Indonesia. Therefore, users of the redBus system should be able to view bus
information, select a bus, a bus seat, and make payment online to complete the booking process. Users
should be able to use the customer support system by using the chat box available to deliver complaints or
enquiry. Next functionality is that users may rate and review their travel experience to other users in which
the rate will reflect on the bus recommendation or popularity algorithm. Users also may be able to track the
bus journey and view the rest stop schedule to know the locations where the bus will make a stop.

Measurement on how well the system has fulfilled this quality is based on user reviews for the
redBus application system taken from Google Play Store. There are positive reviews on the features of the
redBus system. As shown in Figure 7.1.1, this user praised the bus booking system in which the booking
process including the payment system is easy and that the bus information is also displayed correctly with
good coordination with the bus companies. Besides that, the similar user as well as another user shown in
Figure 7.1.2 also claimed that the redBus’ customer service system is great.

24
 Figure 7.1.1 A positive review on redBus application system

Figure 7.1.2 A positive review on redBus application system

Another positive review from a redBus user as depicted in Figure 7.1.3 below is the system provides
options to choose transportation mode and the time of travel. These options are very helpful to users as the
options allow them to travel according to their desired mode and time. From the information mentioned
previously, it can be concluded that the redBus system fulfilled the functionality requirements properly for
these users.

Figure 7.1.3 A positive review on redBus application system

25
7.2 Reliability

This attribute reflects on how well the system performs its functionalities under a certain period. It
is also described as the probability that a system will perform its function in a specific environment for a
set number of input cases with the condition that the input and hardware are error-free [11].

In the case of the redBus system, it is important to be reliable in which its main functionality, the
bus booking feature, must function well under a period of time. First and foremost, consider the system
reliability based on user experiences. There are some user reviews taken from Trustpilot website that clearly
shows that the system is quite unreliable. An example is shown in Figure 7.2.1 where a user claimed that
the redBus system was not working when they tried to book a bus ticket. The system is assumed unreliable
as it was not functioning to do any booking process for more than three hours. Another example is when
the same user finally managed to book one, the ticket was actually confirmed for the wrong date. This
situation can be assumed that there was misaligned coordination of data between the redBus system side
and the travel agency system side.

Figure 7.2.1 A redBus customer’s review on system downtime

More issues that show the redBus system does not fulfil its reliability quality is illustrated in Figure
7.2.2 and Figure 7.2.3. In Figure 7.2.2, the user was not able to proceed to the booking page after selecting
a bus seat. In Figure 7.2.3, the user was not able to complete the date rescheduling process and had tried

26
three times to do so. Both situations are probably caused by the system server and clearly affected the user’s
experience at booking a bus and rescheduling their travel date.

Figure 7.2.2 A redBus customer’s review on the non-functioning booking process

Figure 7.2.3 A redBus customer’s review on the travel date rescheduling process

Another complaint as shown in Figure 7.2.4 below is the redBus system consistently crashed and
the user was unable to proceed with online payment to complete the booking process. When the site
reloaded, the selected seats were suddenly shown unavailable. It can be assumed that there might be a
backend issue which affects the reliability of the system to handle the booking process.

Figure 7.2.4 A redBus customer’s review on redBus system that keeps crashing

27
 Based on the user reviews above, it is important for the developers to take note and avoid the failure
issues. The system reliability is usually measured using the probability and percentage method. Thus, to
ensure reliability of the redBus system, probability of failure should be 0.01 (1 out of 100 searches) when
a user searches for available buses and seats, as well as the travel dates. Probability of failure to make
payment transactions should be 1% too. Next, the probability that the system will be functional and
available every day for 24 hours except during system maintenance should be 99% meanwhile the
probability of failure after the system update should be at most 1%. Another important reliability
requirement that the system is expected to carry out is the probability of failure to submit a form for booking
and rescheduling a bus should be 0.01 or 1%.

28
7.3 Usability

This attribute reflects on the planned aspect of user experience design that ensures users have no
issues using a website's user interface [8]. Besides making things easier, system usability also includes
effectiveness, efficiency, and satisfaction. As illustrated in Figure 7.3.1 below, the redBus Malaysia website
system seems easy for users as they can immediately see the bus search tab when they click on the website
link. The search tab seems easy to use too by having separate input fields for departure place, arrival place,
departure date, and return date. There is also a navigation bar on the top right corner of the site, which eases
users to navigate to their profile accounts, manage their bookings, and go to the ‘Help’ page. There are also
two buttons on the navigation bar that allow users to change the site language and currency. There are two
language options which are English and Malay, as well as two options of currency which are MYR and
SGD. These options make the booking process easier for Malaysian and Singaporean users. All these user
interfaces should generally satisfy users.

Figure 7.3.1 The main page of redBus Malaysia website system

User satisfaction is important when it comes to measuring the system usability. Developers must
take note of the reviews to improve the system usability in the future. In the case of the redBus application
system, there are several user reviews taken from Google Play Store that have mentioned the usability of
this system. As illustrated in Figure 7.3.2, the user was satisfied that the user interface of the redBus system

29
was easy to use. Similarly, the user shown in Figure 7.3.3 claimed that the system was so convenient and
easy, even for a beginner.

Figure 7.3.2 A positive user review on the system usability

Figure 7.3.3 A positive user review on the system usability

However, the redBus system does not satisfy all its users. There are also several negative reviews
taken from the Google Play Store site. One of the reviews, as depicted in Figure 7.3.4, claimed that the
system was confusing to use, that it was messy and had no proper explanation for the bus pass. This user
even made it clear that they prefer to use another system rather than redBus.

Figure 7.3.4 A negative user review on the system usability

30
7.4 Efficiency

This attribute reflects on how well a software system performs according to the number of resources
used by the system and it usually relates to a system’s response time. Based on the user reviews shown in
Figure 7.4.1 and Figure 7.4.2, the redBus system has great efficiency or performance, that system was fast
and rarely lagged for these users.

Figure 7.4.1 A positive user review on the system efficiency

Figure 7.4.2 A positive user review on the system efficiency

To ensure its efficiency, the redBus system uses both SQL and non-SQL databases to manage
different types of modules. For example, the system uses a MySQL database for their OLTP applications
such as payments, user profiles, and transactions. The second database is Cassandra which is used by the
redBus system for the inventory data and the fraud engine. Cassandra is a highly fault tolerant database,
thus it is used to store data from bus companies such as seat layout, and availability in real time.
Furthermore, Cassandra also contained a feature known as Row-level TTL which allows automatic deletion
of any data row from the relational table following the defined TTL configuration. Another database,
REDIS, is used to store inventory systems as the database allows high throughput [14].

31
8.0 REFERENCES

[1]
https://www.tutorialspoint.com/software_architecture_design/software_architecture_design_tutorial.pdf

[2] Tewari, S. (2019, April 15). redBus appoints Mahendra Singh Dhoni as brand ambassador |

Mint. Retrieved December 2, 2022, from mint website:

https://www.livemint.com/industry/advertising/redbus-appoints-mahendra-singh-dhoni-as-brand-
ambassador-1555321742450.html

[3] Srivats, K. R. (2019, January 16). Acko partners Goibibo for travel insurance foray. Retrieved December
2, 2022, from Thehindubusinessline.com website: https://www.thehindubusinessline.com/money-and-
banking/acko-partners-goibibo-for-travel-insurance-foray/article26006200.ece

[4] Tvisha. (2022, August 17). RedBus - Journey. Retrieved December 2, 2022, from @tvishat website:
https://www.tvisha.com/blog/redbus-success-story

[5] Bus tickets online, Ferry Booking: Best Online Bus Booking Platform. redBus Malaysia. (n.d.).
Retrieved November 26, 2022, from https://www.redbus.my/

[6] Features and Tips to make your travel safer. RedBus. (n.d.). Retrieved November 26, 2022, from
https://st.redbus.in/bus/passenger-safety-tips.html

[7] Google. (n.d.). Redbus - Bus Tickets Ferry App. Google. Retrieved November 27, 2022, from
https://play.google.com/store/apps/details?id=in.redbus.android&hl=en&gl=MY&pli=1

[8] Martinez, P. (2020, September 25). What is software usability and how to do it successfully. Mockitt.
Retrieved November 27, 2022, from https://mockitt.wondershare.com/ui-ux-design/software-
usability.html

[9] redBus_Blog. (2018, January 29). Data Flows - redBus. Medium. Retrieved November 28, 2022, from
https://medium.com/redbus-in/data-flows-redbus-31afcfb5f0a1

[10] Redbus is rated "bad" with 1.4 / 5 on Trustpilot. Trustpilot. (2017, April 26). Retrieved November 27,
2022, from https://www.trustpilot.com/review/redbus.sg?page=11

32
[11] Software Reliability . www.javatpoint.com. (n.d.). Retrieved November 27, 2022, from
https://www.javatpoint.com/software-engineering-software-reliability

[12] Understanding Quality Attributes in Software Architecture. InformIT. (2012, October 31). Retrieved
November 26, 2022, from https://www.informit.com/articles/article.aspx?p=1959673&seqNum=2

[13] Gupta, A. (2018, March 7). A closer look on failed payments and refunds at redBus. Retrieved
December 1, 2022, from Medium website: https://medium.com/redbus-in/a-closer-look-on-failed-
payments-and-refunds-at-redbus-1a20ab419918

[14] redBus_Blog. (2017, June 15). Data Flows — redBus - redbus India Blog - Medium. Retrieved
December 1, 2022, from Medium website: https://medium.com/redbus-in/data-flows-redbus-31afcfb5f0a1

[15] Sharma, N. (2018, July 24). Massively Scalable and Fault Tolerant E-Commerce Inventory Platform
(Search) at redBus powered by Erlang/OTP. Retrieved December 2, 2022, from Medium website:
https://medium.com/redbus-in/massively-scalable-and-fault-tolerant-e-commerce-inventory-platform-
search-at-redbus-powered-by-f83fb2d82a28

[16] K, R. B. (2018, August 17). How redBus made use of DialogFlow, Whatsapp — to improve Customer
Experience. Retrieved December 2, 2022, from Medium website: https://medium.com/redbus-in/how-
redbus-made-use-of-dialogflow-whatsapp-to-improve-customer-experience-17c95c68af37

[17] Phaneesh Gururaj. (2018, July 25). User Generated Reviews — classification and tagging — from
redBus. Retrieved December 2, 2022, from Medium website: https://medium.com/redbus-in/user-
generated-reviews-classification-and-tagging-from-redbus-e62b5a5e6951

33