"The term 'microservice' has been widely used since March 2012 to refer to applications developed as a set of relatively small, consistent, isolated, and autonomous services deployed independently, with a single and clearly defined purpose."
gannon.etal.2017.cloudnativeapplications (pg. 3)
All microservices should be designed for constant failure and recovery and therefore they must be as stateless as possible. One should reuse existing trusted services such as databases, caches, and directories for state management.
The reasons for migrating to microservices are manifold. Several participants migrated to microservices simply because it was the only feasible solution for reducing the growing complexity of their systems. Therefore, maintainability as a consequence of the properties of some microservices is the key driver for migration, whereas the increased initial cost turned out to be one of the main issues hindering adoption, even if such costs were highly compensated after the adoption because of the long-term return on investment.
There are three mainstream approaches for using database systems in microservice architectures: (i) private tables per microservice, sharing a database server and schema; (ii) schema per microservice, sharing a common database server; and (iii) database server per microservice [47].
The results suggest that microservices are prevalently deployed in individual containers, predominantly using the database-per-microservice pattern to achieve performance and fault isolation