## 2 Background
### Data Storage in Microservices  
A microservice architectural style is an approach for developing an application as a suite of small services where every service communicates with other services via light-weight mechanisms such as HTTP API. Services are built around business capabilities and are independently deployable by fully automated deployment machinery. There is a bare minimum of the centralized management of services that may be written in different programming languages and use diverse data storage technologies [2]. [PERSON] et al., in the book _Building Microservices Applications on Microsoft Azure_, discuss the various critical factors of designing a database for microservice architecture-based applications [49]. The authors recommend that each microservice should have a separate database because data access segregation helps fit the best technology to handle the respective business problem. The authors, based on CAP theorem, suggested choosing an intersection of two functionalities: consistency and availability, or availability and partition. The database should depend on the nature of the application. While monolith applications usually use a single data store, microservices use many data stores, both SQL and NoSQL. SQL is recommended for use where transactional consistency is critical and structured data are stored. NoSQL is recommended for microservices where schema changes are frequent, maintaining transactional consistency is secondary, and semi-structured or unstructured data are stored. Microservice architecture offers the flexibility to use polyglot persistence. According to [PERSON] et al., there are four main challenges to using microservice architecture and polyglot persistence: (1) maintaining the consistency for transactions spanning across microservice databases; (2) sharing, or making the master database records available across microservices databases; (3) making data available to reports that need data from multiple microservices databases; and (4) allowing effective searches that receive data from multiple microservices databases [49]. To ensure efficient changes transferring across the microservices, the authors suggest using two approaches: (1) a two-phase commit for managing transactions in SQL databases, and (2) eventual consistency to managing any distributed application. [PERSON] et al. attempted to bridge the gap of a lack of thorough investigation on the state of the practice and the major challenges faced by microservice architecture practitioners about data management [25]. The authors identified three main reasons as why a microservice architecture should be adopted regarding data management: (1) functional partitioning is used to support scalability and high data availability; (2) decentralized data management provides the ability to manage data store schemas for each microservice independently; (3) even driven architecture allows one to build a reactive application. Database and deployment patterns were investigated by [PERSON] [25]. Three mainstream approaches for using database systems in microservice architectures were identified: (1) private tables per microservice, sharing a database server and schema; (2) schema per microservice, sharing a common database server; and (3) database server per microservice. Based on the conducted survey, the authors stated that the most preferred and efficient way for data persistence in a microservice architecture is to encapsulate a microservice state within its own managed database server and avoid any resource sharing between different microservices. The most widely used databases in a microservice architecture are Redis, MongoDB, MySQL, PostgreSQL, and MS SQL. [PERSON] et al. researched the implementation patterns for microservice architectures and proposed a pattern language [50]. Part of the proposed pattern language consisted of scalable store patterns used to build a scalable and stateless data store for a microservice architecture-based application.