The microservice approach

If we were to build the same application using microservices, we would organize the code into several separate components that run in separate processes. Instead of having a single application in charge of everything, we would split it into many different microservices, as shown in the following diagram:

Don't be afraid of the number of components displayed in this diagram. The internal interactions of the monolithic application are just being made visible by separate pieces. We've shifted some of the complexity and ended up with these seven standalone components:

1. Booking UI: A frontend service, which generates the web user interface, and interacts with all the other microservices.
2. PDF reporting service: A very simple service that would create PDFs for the receipts or any other document given a template and some data.
3. Search: A service that can be queried to get a list of hotels given a city name. This service has its own database.

4. Payments: A service that interacts with the third-party bank service, and manages a billing database. It also sends e-mails on successful payments.
5. Reservations: Stores reservations, and generates PDFs.
6. Users: Stores the user information, and interacts with users via emails.
7. Authentication: An OAuth 2-based service that returns authentication tokens, which each microservice can use to authenticate when calling others.

Those microservices, along with the few external services like the email service, would provide a feature set similar to the monolithic application. In this design, each component communicates using the HTTP protocol, and features are made available through RESTful web services.

There's no centralized database, as each microservice deals internally with its own data structures, and the data that gets in and out uses a language-agnostic format like JSON. It could use XML or YAML as long as it can be produced and consumed by any language, and travel through HTTP requests and responses.

The Booking UI service is a bit particular in that regard, since it generates the User Interface (UI). Depending on the frontend framework used to build the UI, the Booking UI output could be a mix of HTML and JSON, or even plain JSON if the interface uses a static JavaScript-based client-side tool to generate the interface directly in the browser.

But besides this particular UI case, a web application designed with microservices is a composition of several microservices, which may interact with each other through HTTP to provide the whole system.

In that context, microservices are logical units that focus on a very particular task. Here's a full definition attempt:

A microservice is a lightweight application, which provides a narrowed list of features with a well-defined contract. It's a component with a single responsibility, which can be developed and deployed independently.

This definition does not mention HTTP or JSON, because you could consider a small UDP-based service that exchanges binary data as a microservice for example.

But in our case, and throughout the book, all our microservices are just simple web applications that use the HTTP protocol, and consume and produce JSON when it's not a UI.