An easy way to understand Micro Services Architecture (MSA)


During the last few years, we are increasingly speaking about Micro Services, and how applications should be designed in this style. This is very interesting, but what is lacking when talking with “Mircroservices” fun is a simple explanation why it’s better, and how can i understand the concept rapidly, and imagine my application in this style.

My aim in this blog is to save you pages and pages of lecture by presenting you a quick and simple way to understand MSA (Micro Services Architecture)

1- Our sample application

In order that my explanations be more clear, it will be supported each time be a sample application, that we will call : Hotel Reservation Application (HRA). This is a typical example that many are using, and i insist in using it in order that the picture be always more clear.

HRA provide the following feature:

  • Search and find a hotel room (By City, price, or both)
  • Check the availability of the hotel room during a period
  • Make a reservation
  • Send an email to the user in order to confirm the reservation

For the simplicity of the example, the above features are enough for a user to make a reservation

2- The application architecture after a quick classical reflection

Without any software architecting background and using only the “good sense”, i would imagine my application like the following (we can do better in fact)


The application has two tiers:

  • The frontal part which is a Web Portal
  • The back-end part which is huge server containing my application core features
    • It stores and retrieves the information from a SQL DB

What is bad with this application ?

10 years ago , no one will crtisize this application, but today everyone will have at least one comment:

  • What if the Back-end server is down, all my application will be down
    • In fact no, with horizontal scale, we can achieve high availability be crating at least 2 instances of the back-end server, the web portal will talk with a load balancer, and the load balancer will distribute traffic to the healthy servers

It’s no more a question of high availability, today other questions and challenges rose:

  • I need to update my “check availability” module : This is very complicated since it coexist with all the other modules, you need to check dependencies and interactions with the other modules, you need to make tons of verification and finally you need to redeploy the whole application –> Long application update life-cycle, Risk
  • We have to upgrade the Java or .NET version so our module “Find hotel” supports a very nice feature that will accelerate the search 10 times. Unfortunately, this will beak the “check availability module” since it uses an old library not compatible with new version. Two possible paths:
    • wait for all the other modules to be upgraded to support the new framework update –> Time waste, long application update life-cycle
    • Force the development of the other modules to support the new framework     –> Cost
  • We want to entirely change the programming language (JAVA to .NET or .NET to JAVA –> Kidding me, unless you have solid arguments to justify the huge cost and effort to Business, this is impossible (like JAVA is dead which is impossible too)
  • The “Find Hotel” module is very solicited today, so we are horizontally scaling out our application. Unfortunate, the other modules do not need to be scaled out since they are underutilized. But because the application is ONE, all the application should be scaled, leading to resources waste (since each module consumes by default x resources when idle –> None-optimal resources usage

–> Did you catch it : Monolithic applications have many and many drawbacks and limitations that we can resume them on 3 main points:

  • Limited and poor Flexibility and Extensibility
  • Very long update and release life-cycle
  • Resources usage

–> Does no longer follows the growing “business needs for changes”

3- Micro Services Architecture : It’s no more than good sense

Let me use the limitations of the Monolithic application listed above, to propose a new architecture for my application.


Am i a genius ? No, it’s just a natural reflection. I have just decoupled the modules, so that each module becomes a Service (a small application) that runs on its proper server.

Each Service can communicate with the other service using a known method, and even can be fully isolated from communicating with the other services. Let us take an example:

  1. The user connects to the portal
    • Involved components : Web Portal
  2. The users asks for all the hotel rooms within Paris and selects a Hotel
    • Involved Components : Web Portal, Service 1, DB
  3.  The users checks the availability for the room between 20 and 30 September
    • Involved Components : Web Portal, Service 2, DB
  4.  The users makes a reservation for that room
    • Involved Components : Web Portal, Service 3, DB

Waw, we demonstrated that each Service is independent of the other by proof, and here is my contribution to the community : WHAT DO WE MEAN BY INDEPENDENT, because without Service 1 i can’t  find the hotel room for step 3.

The characteristic of MSA are the following (Inspired by this excellent article )

  • Service Independence
  • Single Responsibility
  • Self-Containment

3.1- Service Independence

My explanation for Service Independence is the following : During the service execution, an Independent Service  should not rely on any another service to complete a task.

NB : The data store (like the database or a file) is not considered as a service

Our application can testify:

  • In order to find a hotel, i will submit a request to the Find Hotel service with a set of parameters (city and price). When the service handles the request and starts its execution, it will only communicates with the DB to achieve its goal. Then it will send back the result to the portal. The task is completed
  • In order to check for the availability, i will submit a request to the Check Availability Service with a set of parameters (hotel room, period). When the service handles the request and starts its execution, it will only communicate with the DB to achieve its goal. Then it will send back the result to the portal. The task is completed
  • In order to reserve the room,  i will submit a request to the Make reservation Service with a set of parameters (hotel room, period, availability OK, CardID). When the service handles the request and starts its execution, it will only communicate with the DB to achieve its goal. Then it will send back the result to the portal. The task is complete

Note that during the service execution, it dos not rely on other services to complete. The service needs only inputs to start.

3.2- Single Responsibility

Single responsibility means that the service is responsible for providing a single business capability that, by using the good sense cannot be further divided. When i say Using the good sense, it’s because we can divide anything till we reach the CRUD operations. Single Responsibility means that the service has a logical and business function, which can be seen as un-split-able. For example, in our example, the Check Availability Service has a single responsibility : to check if a hotel/room is available. The Reservation Service on the other hand, is quiet different, since it contains two functionalities that logically can be divided (Good candidate for an enhancement)


3.3- Self Containment

This is an important properties, specially for whom are responsible of developing the application. Self Containment means that the Service should contains all the necessary “code” to run without the need for external interactions or modules. This is solely related to the Properties 1 (Service Independence), but at the code level. Ensure that the Service does not rely on an external modules or dependencies when executing. The code lifecyle should be independent by means. For example, updating a “Function” related to Service 1 should not break Service 2.

4- What next ?

This post is a simple introduction to understand the Micro Services Architecture. The goal is to demystify the concept and to start having a proper thought about your ability to design and imagine your application, or a new application using MSA. Keep in mind that:

  • Not all applications are suitable for a MSA
  • Switching from a monolithic app to MSA has to be considered carefully and wisely : May have multiple advantages, but also requires a huge effort
  • There is no ONE MSA for an application. Two Software Architects may bring different designs. Study them deeply and identify the best, according at least to the 3 principles mentioned above.

Note : What do you thing of my Service 3 in my sample Application, any note ? Can it be enhanced : Why and How ?

One thought on “An easy way to understand Micro Services Architecture (MSA)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s