As we described previously, a microservices architecture is based on a loosely coupled set of services that work together to achieve a specific target application. At the end of the spectrum, there are monolith applications.

A monolith application is composed of a set of components that are tightly coupled. These components are usually developed using the same language and the application runs as a whole. The first noticeable difference is probably the slow start. Deploying might also be slow since you might need a couple of dependencies before having anything up and running.

Let's imagine an event application, a simple one, an application that lets users define events and be notified when those events are about to start.

Let's describe what the event application does:

• It allows users to register themselves and add events to a calendar
• A few minutes before the event starts (that's what the Scheduler component is for), the users receive an email with the event information (that's the SMTP component)
• Users can use the frontend interface or the API interface

Imagine the preceding application as being a monolith (the greyed out area on the right). Imagine that all four parts are part of the same process, even though they could be in separate threads. Imagine that the database is accessed directly across the application. Sound good?

Well, it sounds terrible, perhaps not for a small application, but for a medium one, this would be a representation of chaos. Having a group of developers making new features or improvements would be a nightmare, and for new developers entering the group, it would take some time before having the base knowledge to make some changes.

The first principle that you should follow is the Don't Repeat Yourself (DRY) principle. Avoiding multiple components from accessing a data source helps developers in the future. Later on, if there's a need to change the data source or part of its structure, it will be easier if only one component manipulates it. This is not always possible, but if it is possible, you should keep the data source access to a minimum.

In our example, the API should probably have access, and all others should use the API.

We now have two services:

• The API, which is the only service accessing the data source
• The frontend, which is the user's interface to change the data source

Although the frontend is used to manage events, it uses the API service to manipulate data sources. Besides having only one service managing data sources, it forces you to think of the API for external developers. It's a win-win.

There is still room for improvement. The Frontend could be in a separate service, allowing you to scale the interface according to user traffic, and have the other parts on separate services. Scheduler and SMTP are both candidates for separate services. SMTP should be thought of as a reusable service for other applications you might develop later on.

Let's take a look at how we could build the same application using the microservices approach:

It looks more complex. Well, the architecture is more complex. The difference is that now, we have loosely coupled components, and each one of them is easily understandable and maintainable. Summing up the changes and advantages:

• The API is the only one accessing the database so it can change from SQLite, MongoDB, MySQL, or anything else, and no other component is affected
• SMTP can be used from the Frontend and Scheduler, and if you decide to change it from using a local service to using a third-party email sending API, you can make the change easily
• SMTP is a candidate for being a reusable service in other applications, meaning you can use it in other applications or event share the same service between multiple applications

You can think of these components as capabilities of your application. They can be swapped, upgraded, maintained, and scaled, all without affecting other components or your application.

A commonly underestimated advantage of using this approach is that your application is much more resilient to failures. In a monolith application, any part can bring your application offline. In this microservices approach, this application might not send emails but can still be running and accessible. Add caching into the mixture and the API can restart in moments.