Discussing programming languages is something that can be controversial, primarily because many developers tackle programming languages in a great hurry. However, programming languages should be seen as what they really are, a working tool. Every tool has a specific purpose and programming languages are no different.

It is just an analysis focused on our business, the news portal, which we will use to get to the point of how to select a language.

A big plus point for microservices is the heterogeneity of applications. In other words, it is not necessary to think of a single stack to apply to all business areas. We can thus define each microservice stack that applies, including when it comes to a programming language.

Basically, any programming language that meets the internet can be used in microservices. The difference is due to the requirements and domain...

When dealing with frameworks, we have to think that because of the technological diversity of our frameworks, we will have at least three frameworks instead of one to keep our ecosystem.

Of course, we could have kept all microservices in the same stack. However, searching for the best overall performance for each domain, we opted for a more plural stack.

Obviously, at first, the impression is that the complexity will be higher than expected. But this type of complexity is matched by the performance most suitable for each case.

Basically, we chose three different programming languages to use on our news portal. Python, Go, and C# are those languages. It is time to think about which frameworks we will use for each of these languages, thus taking another step in shaping our development stack for each microservice.

Much is discussed about microservices communication; topics such as protocols, layers, types, and package sizes are widely discussed when it comes to the subject.

The point is that communication between microservices is the most critical topic for project success. It is very clear that the amount of positive factors increases with microservices architecture, but how to make the communication that does not encumber the performance of a product to the end user is the key point.

It does not help that all the practicalities of developing and deploying the product do not scale or the end user experience is compromised.

There is a lot of literature and study material on the subject, but the challenge still remains. And oddly enough, even with all the available material, making mistakes in this part of the project...

In the previous topic, we talked about synchronous communication between microservices using binary and alternatives to REST. This topic will deal with the communication between microservices using message broker, that is, a messaging system with a physical element, a communication layer, and a message bus.

With messaging systems, it is impossible to reproduce the Death Star. The design of the Death Star in a more robust application would be something like the following:

The diagram of a messaging system is totally different, similar to the one shown in the following:

The message bus can be used for both synchronous and asynchronous communication, but certainly, the major point of emphasis of the message bus is in asynchronous communication.

You may wonder, if the messaging diagram is simpler and you can use this type...