Article by Jorge Berjano, Software Architecture at decide4AI.
Every day we generate millions of data through our actions and interactions with different devices. In this hyper-connected era, technological ecosystems have had to evolve to adapt to this new paradigm of massive data, which the old systems could neither support nor process.
As a result of the need for companies to have high availability of data and to be able to create and manage products and services in a scalable and fast way, different types of architectures and software patterns have been appearing to help achieve these objectives. Let’s take a look at the main paradigms:
Microservices Architecture
Microservices architecture is a method of software application development that works as a set of small services that run independently and autonomously, providing complete business functionality.
Microservices have created more adaptable and flexible IT infrastructures. Because if you want to modify just one service, you don’t need to alter the rest of the infrastructure. Each of the services can be deployed and modified without affecting other services or functional aspects of the application.
Microservices communicate with each other through APIs, and have their own storage systems, which prevents application overload and crashes. They allow the subsystems that need it to be scaled horizontally and facilitate integration and continuous deployment (CI/CD).
Command-query reponsibility-segregation (CQRS)
CQRS can be approached as a design pattern for coding or as an architectural pattern in a microservices environment, which applies the principle of separation of commands (requests by the user or another system to perform a business operation, which evolves the system from one state to another) and queries.
They may have several specialised query or command subsystems, where, as the name suggests, one is responsible for commands and the other for queries.
Each of the subsystems has a different design, persistence mechanism and information model, optimised for the tasks they have to cope with. They can scale independently and use caches and data prefetching to provide faster response. On the downside, as there is often duplicate data, it is more complex to maintain data integrity.
Event Sourcing (ES) and Event-Driven Architecture (EDA)
Events are significant state changes in a system, e.g. a change from “task in progress” to “task completed”. This event that has occurred triggers the emission of a message (event notification) that is published, propagated, detected and consumed by other applications within the architecture. Event-Driven Architecture (EDA) is a software architecture paradigm that promotes the production, detection, consumption and reaction to events.
An event-driven system consists of applications and systems that transmit events in real-time between software components and services. There are components that are event senders, event consumers and event channels. Emitters detect, collect and transfer events, consumers apply a reaction when an event occurs, and event channels are the event transmission pathways between transmitters and consumers.
Event messaging systems are a more flexible alternative to communication via RESTful API requests. The idea is to communicate asynchronously across the ecosystem of microservices using message queues that function as buffers, avoiding saturation in the services that consume the events, solving backpressure problems. For greater speed in this type of architecture, queries are made against intermediate relational databases, with prepared data.
Reactive Programming is often used when working with message queues, which significantly facilitates software development.
All events are stored so that there is a history of all modifications to the systems. In addition, analysis tools can be used to see how the event flow, containers, services or message queues are working in order to detect failures or inefficiencies.
Domain Driven Design (DDD)
Systems that apply the above paradigms often make use of the practices outlined in domain-driven design.
Domain-driven design (DDD) is a software development approach that emphasises the connection between the implementation and the business model. In it, the different subsystems have a direct correspondence with the concepts that the client and its business experts handle, promoting a ubiquitous language to further facilitate understanding between the parties. It aims to accelerate the development of software projects that have to deal with complicated domains.
Conclusions
There is no doubt about the increase in applications that provide all kinds of services at a global level, such as online sales platforms, social networks, streaming audiovisual content and an endless number of applications that exist and are yet to come, for which the old monolithic application paradigm is unfeasible.
The focus of these new architectural paradigms is to provide an optimal solution to the new challenges facing software development today, where the absence of delay in the user’s interaction with the applications is of crucial importance to achieve complete satisfaction. This, coupled with a large amount of users and data being handled, requires new strategies to address this goal.
It is not surprising that in recent years new models have emerged that break with pre-existing approaches, not only at the level of architecture but also at the methodological level. Some may interpret this as a passing fad, but I think it is more objective to see it as an evolution towards something that will improve and facilitate software development in the future.
if you want to know more about types of architectures and software patterns for data exploitation, do not hesitate to contact us:
Do you want to learn more about decide4AI and keep up to date with future webinars or actions? Follow us on social networks (Linkedin, Twitter, Youtube).
