# Developing Microservice-Based Applications Using the Silvera Domain-Specific Language
## 2 Related Work
### MSA Design Patterns  
In this section, we define design patterns that will be used in the rest of the paper.  
A design pattern is a reusable solution for a problem that occurs in a specific context. [PERSON] [27] proposes a taxonomy and describes design patterns used in MSA. In the rest of the paper, design patterns from the following categories will be considered: _Deployment_ patterns, _Communication_ patterns, _External API_ patterns, _Reliability_ patterns, and _Service Discovery_ patterns. Each of the previously mentioned categories can contain multiple different design patterns, as shown in Table 2.  
_Deployment_ patterns provide a solution to the problem of packaging and deploying microservices. Patterns such as _Single Instance Per Host_, _Multiple Instances Per Host_, _Single Instance Per Container_, and _Serverless_ are all deployment patterns. In the case of the _Single Instance Per Host_ and the _Multiple Instances Per Host_, a _Host_ can be either a physical or a virtual machine (VM). The most popular deployment pattern, both in industry and academia, is the _Single Instance Per Container_, followed by the _Single Instance Per Host_, where a host is a VM [28]. There are several reasons why containers are preferred over VMs [28]: (i) creating and launching container images are often very fast, (ii) the same physical server can hold more containers than VMs due to their size, and (iii) more than one container can use a single operating system, which in turn reduces the overhead of licensing costs compared to the VM.  
Microservices must handle requests from external clients, but often they must collaborate to perform a certain task. The role of _Communication_ patterns is to provide a solution for a problem of communication between the parts of the system. The most prevalent communication patterns in microservice-based systems are _Remote Procedure Call_ (RPC) and _Messaging_. With RPC, microservices can communicate either in a synchronous or asynchronous manner, whereas with _Messaging_ the communication is always asynchronous. According to [PERSON] et al. [28], it is not possible to determine the most popular communication pattern, since the selected pattern can change over time as the system evolves.  
How microservices will establish a connection is further described by _Service Discovery_ patterns. The _Service Registry_ pattern ensures the existence of a service registry, which represents a database that contains the data model of available microservices deployed in the platform [29]. A service registry is a critical part of the system and must be highly available. The responsibility for registering or unregistering a microservice within a service registry can be put either on the microservice itself (_Self-Registration_) pattern or the third party (_Third-Party_) pattern. Similarly, the responsibility for discovering a microservice can be either on the client side (_Client-Side Discover_) pattern or on the server side (_Server-Side Discovery_) pattern.  
_External API_ patterns describe exactly how external clients will communicate with microservices. An _API Gateway_ provides a single entry point for all external clients. To avoid a single point of failure, multiple instances of an API gateway are usually deployed [28]. Additionally, a separate API gateway can be provided for each kind of client (web app, mobile, etc.). This variation of an _API Gateway_ pattern is a _Back-End for Front-End_ pattern.  
Microservices are _built to fail_[30]. The solution for the problem of preventing the microservice failure to cascade to other microservices is provided by a _Reliability_ pattern named _Circuit Breaker_.