I’ve just published an article about how an e-commerce system can be reshaped by using the Kafka ecosystem.
The “metamorphosis” of that e-commerce system was started by decoupling the main/central web application through which customers can interact with the system from all the other external components to which it was coupled synchronously. This decoupling was powered by a multitude of patterns implemented by using Kafka Connect components.
I will continue by showing one by one how all the patterns described above can be actually implemented.
The basics of this scenario were covered in the “Metamorphosis of an e-commerce system by…
I have written in the past about some lessons learned about building microservices and reactive systems.
Starting with this article I will continue with showing a concrete scenario where some of the principles that I have written about have been applied. Also, I will add some code snippets for showing how to apply those patterns by yourself.
Let’s imagine that we are facing a legacy e-commerce system that is too coupled in a synchronous way to a high number of external components. …
Being involved in a project where Quarkus is intensively used, I’ve started to work on some integration tests and system tests where I’ve involved the persistent storages as well.
I’ve said persistent storages, yes, we have two: Microsoft SQL Server and Amazon S3. I will try to show next how both of them can be integrated for real into the testing part by using Testcontainers, without creating mock objects, like usually.
Today’s article will be oriented to a very specific concept, which is the In-Memory Data Grid or IMDG, discussing all the ideas introduced by this one.
IMDG is a general or abstract concept, which describes a way to leverage some kind of distributed system for storing data and performing in-memory computations on stored data.
Being an abstract construction, we will dive into a concrete implementation of the concept, looking specifically at Hazelcast In-Memory Data Grid.
What is an In-Memory Data Grid (IMDG)?
First of all, let’s introduce the concept of Data Grid. A Data Grid is a system of multiple…
Modern distributed systems, especially microservices, are hard to be designed, developed, and maintained, as we’ve already seen in one of the previous posts, where were discussed more some key principles that should be followed when working on a microservice-based architecture.
We have seen that at this moment the most complete idea about building this kind of system is given by the Reactive Manifesto. In this set of principles, the most important one is the responsiveness of our system. This is achieved by building an elastic and resilient system on top of message-driven integrations between components of the system.
In the previous blog post, I’ve shown what was the lessons that I’ve learned when I’ve worked in building reactive microservices. In the current article, I want to show you what are the methods that I’ve seen that allowed for gaining proper isolation and decoupling between microservices.
First of all, I will start by assuming that most of the software engineers are thinking that if two whatever software components (eg: two functions, two classes, two microservices, two systems, etc.) do not share anything and are not integrated in any way, then the perfect construction was achieved. Scaling the…
I think that this will be the first blog post from a series in which my purpose is to share with you my experience when working with distributed systems.
For some time microservices are the most used architectural style and also the point that every software engineer wants to reach. During time microservices have undergone some changes and in this way, we have reached out at concepts such as miniservices, self-contained systems or reactive microservices and, reactive microsystems as defined by Jonas Bonér.
My point of view is that all these concepts share some fundamental to-be followed ideas, let’s called…
Living in a reactive, full of actors, distributed system.