Reactive architecture

Reactive architecture is a type of architecture based on the principle of message exchange.

Message exchange helps reduce coupling between system components, enhancing reusability, enabling independent testing, and simplifying component interaction within the system.

Reactive architecture is not exclusive to microservices or event-driven systems; it can also be implemented in modular monoliths, allowing for a flexible transition to separate, independent components in the future.

It is built upon four principles outlined in the Reactive Manifesto.

график закона

Key concepts:

  • Responsive (availability, responsiveness)
  • Resilient (fault tolerance)
  • Elastic (flexibility, scalability)
  • Message-driven (message exchange)

Amdahl's Law

график закона

Availability
Applications must respond to requests on time. It’s not always necessary to meet strict real-time requirements; soft limits within reasonable boundaries are also acceptable.

Resilience
Applications must remain available even in the event of failures. Mechanisms for achieving this include:

  • Replication
  • Containerization
  • Asynchronous delegation
  • Monitoring of:
    • Resources
    • Logs
    • Failed user actions (business-level monitoring) Monitoring should be based on a "sufficient margin." For example, an average network load of 50% is already a reason to consider adding more resources.

Elasticity, scalability
The architecture should consider load balancing that adapts to various loads and flexible methods for scaling resources.

Mechanisms for achieving this include:

  • Vertical and horizontal scaling

Message exchange

  • Location transparency
  • Non-blocking processing
  • Asynchronous communication

Monoliths typically rely on direct, transactional, synchronous data exchange. The mechanism to achieve ACID is:

  • Atomicity
  • Consistency
  • Isolation
  • Durability

Reactive architectures always involve eventual consistency. To approximate ACID, compensating requests (Compensating Transaction Pattern) are used. One such approach is the Saga pattern.

Compensating requests work through:

  • Choreography (each service listens to what others are doing and adjusts accordingly; each transaction publishes events that trigger transactions in other services)
  • Orchestration (a central service makes decisions, and others follow)

The main problem is that there’s no single state to roll back to, as each service has its own state. If the compensating transaction fails, the question arises: what now?

There are several options, but none of them are ideal:

  • Retry multiple times
  • Notify monitoring about the issue

A simplified interaction example is RxJS.

Services are the main point of interaction.
Snapshots are state sources.
Subscription queues: parameters and data.
Components generate actions directly, responding asynchronously.
Views follow the MVVM model.

CQRS (Command Query Responsibility Segregation) separates responsibilities for commands and queries.

CQRS does not mean that Event Sourcing (storing actions that change state instead of the state itself) must be used.

CQRS

Instead of Event Sourcing, you can use CQRS + Saga.

CQRS includes:

  • Event Bus
  • Command Bus | Query Bus

Saga includes:

  • Commands
  • Compensating transactions

Comments

Post a Comment

Popular posts from this blog

Books Every Developer Should Read (In My Opinion)

You know those moments when you want to chill but still feel productive? As a developer, those are the perfect times to pick up a book that sharpens your mind without making it feel like work. Over the years, I've come across some gems that aren’t just about cranking out code but about shaping the way you think, collaborate, and grow as a programmer. Here are a few books I’d recommend when you’ve got some free time and want to grow beyond the syntax. 1. The Pragmatic Programmer by Andrew Hunt and David Thomas This one’s a classic. If you haven’t read it yet, you’re missing out. It’s like the ultimate toolbox for practical thinking as a developer. They cover everything from version control to code hygiene in such a way that you feel like you’re learning from two seasoned mentors who get it . It’s more about mindset than language specifics, so it’s evergreen. Why read it? Because it makes you better at your craft without overwhelming you. Takeaway: Software craftsmanship is about ...
Read more

TypeScript: Why It's Needed and Why It's So Popular

Image
JavaScript code should work predictably in any situation. We could add many checks to our code, but that would make it bulky and hard to maintain. We could also add comments and hints, but they won’t protect us from incorrect code usage. In this situation, TypeScript comes to the rescue. Let’s explore why it's so useful for JavaScript developers. What is TypeScript? TypeScript is a strongly typed programming language based on JavaScript. It consists of three main parts: Language syntax, Compiler, Editor service. TypeScript syntax allows developers to express solutions elegantly in .ts or .tsx files. It’s an evolution of JavaScript’s syntax, meaning any JS program is syntactically valid in TypeScript. The tsc compiler helps catch many defects before deployment. It transforms TypeScript source code into JavaScript and analyzes the program to identify potential issues. TypeScript can generate .js files for any version of JavaScript, starting from ES3. Deve...
Read more

Reactive Architecture at the Code Level

Until now, we have considered reactive architectures at the system level. The implementation of such systems is based on message or event exchanges. Queues are typically used as the medium for propagating events or messages, while simple message buses are less common. We previously discussed the difference between a bus and a queue, and today we’ll talk about how reactive architecture is implemented at the code level. The core of implementing reactive architecture at the code level still revolves around messages, though the methods for message dissemination are not necessarily based on queues. Reactive patterns used at the code level typically implement a "data stream" approach, allowing for modular or micromodular implementations. This approach works especially well in stateless systems where the order of data processing is not important, though it can also be applied in scenarios where order matters (e.g., using the SAGA pattern). Today, we’ll focus on error-handling strate...
Read more