## 2 Background
### Data Storage in Microservices
The key in these patterns is that the database must be naturally distributed and able to both scale horizontally and survive the failure of a database node. The authors suggest choosing a database based on the need: if the application strongly depends on the SQL-centric complex query capability, then a solution such as a SQL database or a distributed in-memory SQL database may be more efficient, otherwise, the recommendation is to use NoSQL databases. The importance of data persistence choice in microservice architecture-based applications was highlighted by [PERSON] et al. in the article \"Assessing Architecture Conformance to Coupling-Related Patterns and Practices in Microservices\" [51]. According to the authors, three things have to be taken into account while choosing data storage: reliability quality, scalability quality, and adherence to microservice architecture best practices. The most recommended option is the database per service pattern and the second option is to use a shared database, but this way negatively affects the loose coupling quality. [PERSON] et al. proposed and tested a simplified database pattern for microservice architecture where a database is a separate microservice itself [52]. The proposed data persistence pattern was based on four patterns: (1) the API gateway pattern; (2) the client-side discovery and server-side discovery patterns; (3) the service registry pattern; and (4) the database per service pattern. Proposed pattern benefits are: no traditional service layer, microservices has no third-party dependencies, database microservice encapsulated all specific database details, less involved components, and less complexity. The main drawback is the dependency on the chosen database. Proof-of-concept showed an improved performance compared with the standard SQL based storage. [PERSON] et al. evaluated the use of a multistore database canonical data model in microservice architecture [53]. The authors proposed and implemented an architecture for microservices with polyglot persistence based on the strategy of a canonical data model. The benefits found during the evaluation were: (1) usability--high understandability and operability; (2) high performance--better resource utilization and shorter response time; (3) compatibility--the proposed architecture has enabled systems implemented with different technologies to coexist in an encapsulated form; and (4) maintainability--the API structure provides processing of the linked objects (as defined in the scheme) in a segregated manner, facilitating the decomposition processing logic and improving the readability of the mediator node code. A different approach of data persistence in microservice architecture was presented by [PERSON] et al. in the paper: \"Synapse: A Microservices Architecture for Heterogeneous-Database Web Applications\" [54]. The authors developed a framework called Synapse, which supports data replication among a wide variety of SQL and NoSQL databases including MySQL, Oracle, PostgreSQL, MongoDB, Cassandra, Neo4j, and Elasticsearch. With Synapse, different microservices that operate on the same data but demand different structures can be developed independently and with their own database. Synapse transparently synchronizes shared data subsets between different databases in real-time. Synchronization is conducted via a reliable publish/subscribe communication mechanism. The biggest advantage of the synapse is that it enables microservices to use any combination of heterogeneous databases (SQL and NoSQL) in an easy-to-use framework.