JOURNAL OF IEEE INTERNET COMPUTING 1 Performance Analysis of Microservices Design Patterns Akhan Akbulut, Member, IEEE, and Harry G. Perros, Fellow, IEEE Abstract—Microservices-based solutions are currently gaining momentum because they do not have the disadvantages of traditional monolithic architectures. Business interest in mi- croservices is increasing since the microservices architecture brings a lightweight, independent, reuse-oriented, and fast service deployment approach that minimizes infrastructural risks. This approach is at an early stage of its development, and in view of this, it is important to understand the performance of its design patterns. In this paper, we obtained performance results related to query response time, efficient hardware usage, hosting costs, and packet loss rate, for three microservices design patterns practiced in the software industry. Index Terms—Microservices, Design Patterns, Microservices Architecture, Performance Analysis, Software Architecture I. I NTRODUCTION T HE service-oriented architecture (SOA) is the most widely used concept in software design. This is because it enables high service reusability, reliability, improved scalabil- ity and availability, heterogeneity, and platform independence. SOA is currently evolving to encompass microservices so that to address problems related to the boundaries of the monolithic architecture [1]. Application requirements have given rise to the need for the lightweight and high scalability option pro- vided by the microservices architecture. Microservices break the logic of an application into a number of independent services that run as separate processes. This approach can lead organizations to the realization of a true SOA that will permit business processes and data to become more available. Enterprises that have recognized the benefits of microser- vices have started to replace their existing legacy software with microservice-based solutions. In view of this, it is very critical to accurately determine the application architectures for effective use of this relatively new technology. The success of microservices architecture depends on the use of design pat- terns. A number of patterns have been proposed in MuleSoft’s whitepaper [2], Arun Gupta’s blogs [3], and in some books [4], [5], [6]. In this paper, we report on performance results we obtained by implementing various applications using the API Gateway, Chain of Responsibility, and Asynchronous Messaging design patterns. The performance results are related to the query response time, efficient hardware usage, hosting costs, and packet loss rate. A. Akbulut is with the Department of Computer Science, North Carolina State University, NC, USA and also with the Department of Computer Engineering, Istanbul K¨ ult¨ ur University, Turkey. e-mail: aakbulu@ncsu.edu, a.akbulut@iku.edu.tr H. Perros is with the Department of Computer Science, North Carolina State University, NC, USA. e-mail: hp@ncsu.edu II. PERFORMANCE ANALYSIS In our testbed, we used Node JS v.8.11.4 and Python v.4.7.0 for the implementation of the microservices, MongoDB v.4.0 for the data source platform, and Docker Compose v.1.22.0 for the containerization environment. The Docker environment was deployed on an Ubuntu 16.04 LTS Base system in the Virtual Computing Lab (VCL) of North Carolina State University [7]. Docker containers were restricted by cgroups so they do not consume the full resources of the testbed. They only worked as virtually configured hardware. All experiments use the following 3 main components; a tester, an analyzer and web resources implemented in mi- croservices related to the experiment. The tester generates web customer requests that are executed by the microservice environment. In all the experiments, we evaluated the response time of an implemented application, i.e., the time it takes to process a request, by subjecting the application to a maximum load. To this effect, the tester was implemented as a multi- threaded structure which generates a predetermined number of threads. Each thread issues 3000 requests back-to-back in an asynchronous manner, and when all the responses to the requests are received, the thread is deleted. Each thread records the time at which a request is issued and the time at which the response to the request is received in a text file. All the text files generated in the experiment are processed by the analyzer in order to calculate the mean and confidence interval of the response time, and also the 95th percentile of the response time. The latter metric is a value of the response time such that only 5% of the sample response times are higher. We note that this is a more meaningful metric in Service Level Agreements (SLAs) than the mean, since it provides a statistical upper bound. Other percentiles, such as 99%, can also be used. A. Case Study 1- The API Gateway Design Pattern This pattern consists of a gateway through which a number of different sub-services are accessible. An API Gateway acts as a single entry point for requests and based on the nature of a request it invokes an appropriate sub-service [8]. In addition to routing and aggregation, an API Gateway performs two important tasks, namely, gateway offloading and circuit breaking. Case Study 1 is an implementation of an online theater system using the API Gateway pattern on a 4 core Intel CPU (2.0 GHz) with 16 GB RAM server. The system consists of four services. the Movies service provides general information and the Sessions service gives a list of the show times of the movies and the theater name. The tickets service is