Called on to refine service-oriented architecture, a new architectural pattern named microservices emerged in the early two-thousands promising to speed up the delivery of new features. All of this is achieved by allowing many teams to work on separate autonomous parts of an application independently, though steepening the learning curve and introducing infrastructure-related issues. Overtime, while gaining more popularity, the initial meaning, as well as peculiarities of distributed systems development and reason for the use of the pattern, has turned out to be less prominent, instead becoming a sliver bullet for monolithic applications, which irreversibly leads to a tremendous increase in complexity of a system as well as other inherent problems. The absence of a single definition as well as the misleading name of the microservices pattern has all contributed to the development of the notoriously known distributed monolith. In this document, a review was conducted to resurrect the notion of microservices, understand their nature, and how and when the pattern should be applied. This is done by firstly understanding the difference between monolithic and distributed systems including their strengths and weaknesses, and defining the single most important reason for microservices to be used. The main part focuses on reducing the coupling in the system, which is the main obstacle during the development of a reliable and agile distributed system. Firstly, by modeling boundaries following domain teams and architectural needs, we ensure autonomous deployable units are created that provide independence during development, isolation, and reliability. Later by analyzing approaches to sharing data and communication, which are two major forces structuring a distributed system, we secure the previously established boundaries.