The Dev World – Sergio Lema

Each application must follow a clear architecture design.

Why?

This way, each decision, each new feature will go in the same direction.

In this article, I explain the 5 most used architectures.

Layered Architecture

Let’s start with an example. A hotel booking backend application. It receives requests from the frontend, handles the request and performs some actions in a database.

A request needs to go through several layers:

• The controllers layer to receive the request, to parse the received value and call the adequate services.
• The busines layer to compute the request, or to calculate the requested values.
• And the database layer to read and store values in the database.

There may be more layers. But the objective is to organize them vertically, to isolate them.

The controller layer can’t access the database layer directly, only the business layer can.

But there are also vertical layers. I must separate the business in different services. All the business logic to compute the price for a night in a hotel must be in a separated service than the logic to fetch all the images of a hotel.

How can communicate different business layers?

The top layer, the controllers layer is the one responsible to request all the needed business services. It call each services and builds the requested response.

But I can be more lax.

I can allow horizontal communications. The price service can request the hotel service.

What I should never allow is diagonal communication. I must forbid the price service to access the hotel data directly.

Having the clear logic and business separation I follow the Separation Of Concerns, SOC, pattern.

This architecture is usually aplied to single monolith applications.

Service Oriented Architecture

If I want to separate even more the business logic, I can put it in separated application.

Here comes the Service Oriented Application, SOA.

I may need different server resources for the services. Or I may need high availability on some services. But I don’t need to go as far as using Microservicies with all what this implies.

With a SOA, I can keep a single database to store all the application data.

With a SOA, I have several applications which are responsible for a single business logic.

Inside each single application, I can apply again the Layered Architecture.

Pipeline Architecture

The Pipeline Architecture is mainly used in data oriented application.

The data is flowing from service to service until the end. On each service, a transformation is made.

The separation of business logic still exists. Each service is charged of a single business transformation.

Let’s take an example.

I have a hotels booking application. And at night, my Pipeline Application needs to compute some data to deliver emails.

The first service will be the one that fetches the booking rows in the database . Not all the rows are concerned in this batch process.

The output of the first services goes now to the second, to fetch the hotels information (name, city and main picture). The second service will group all the request to avoid making a query to the hotel table in the database per booking row.

The output of the second service will be the booking lines enrich with the hotel data. And this goes to the last servixe.

The last service will only be responsible to send emails. For each line received, one email is sent. The logic present in this service is only the email configuration.

In the Pipeline Architecture, each service can have its own server (as the Microservices Architecture or the SOA Architecture) , or be grouped all together but separated in different packages (as the Layered Architecture).

The comunication between the services is synchronuous. If an error occurs in a service, it must be handled. This means that the error must not be propagated to the other services and the pipeline execution must continue.

Event Driven Architecture

Similar to the Pipeline Architecture is the Event Driven Architecture. But this time asynchronous.

The usage can be the same: send emails depending on the booking made during the day.

But with the Event Driven Architecture I can go a step further. I can calibrate the load of each service individually.

I can have two instances of a service realize a single task.

Each service consumes data from a queue and produces data to a queue. But I can have several consumers of a single queue. This way I handle the data of a single step faster.

And as all the steps are not coupled, as the communication between the steps is now asynchronous, there is no problem if two consecutive steps have a different rate.

Microservices Architecture

With the Microservices Architecture, each business logic is separated in a single service. And I can run several instances of a single service.

Having several instances of a single service gives the application more resilience.

If a single instance is shut down due to a problem, I have a second one to handle the incoming load.

I can also configure the resources allocated to each service individually.

With the Microservices Architecture also comes an orchestrator, like Kubernetes. The orchestrator is responsible to maintain the services up and running.

The orchestrator is responsible to increase the amount of instances of a single service if its load increases. It’s also responsible to restart an instance if it goes down. Or stop redirecting requests to a slow instance.

Conclusion

The previous architectures can be combined to adapt the need of the application.

But the goal is to have the main architecture clear in all the development team. This way, each new feature has a clear place to go.

Having a clear architecture in mind avoid the development team to make decisions that lead to spaghetti code or bad practices.