DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Last call! Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Serverless Patterns: Web
  • How to Practically Implement Microservices Infrastructure in Your Business
  • Designing High-Volume Systems Using Event-Driven Architectures
  • Microservices Architecture: What, When, and How

Trending

  • Understanding Java Signals
  • A Guide to Developing Large Language Models Part 1: Pretraining
  • The Role of Functional Programming in Modern Software Development
  • Apache Doris vs Elasticsearch: An In-Depth Comparative Analysis
  1. DZone
  2. Data Engineering
  3. Data
  4. Reactive Microservices - 1

Reactive Microservices - 1

This article explains reactive systems, reactive programming, and reactive microservices.

By 
Kapil Raina user avatar
Kapil Raina
·
Updated Aug. 11, 21 · Analysis
Likes (8)
Comment
Save
Tweet
Share
6.1K Views

Join the DZone community and get the full member experience.

Join For Free

Prologue

The term reactive is ubiquitous. Everything from architecture to frameworks, to the general concepts, seems to refer to this term. Quite obviously, reactive has assumed many meanings and definitions and can be understood under a certain context. This article aims to dive deep into what being reactive means and to explore the various contexts where this idea is used. In particular, the article aims to explore the relationship between microservices and reactive and attempt to define what reactive microservices are.

Reactive Systems — Introduction

The operating environment of enterprises today has complexity as a norm. Cloud Computing, Multiple device types (desktops, mobile devices, wearables, Sensors, Gaming Consoles, Smart Homes), near-zero downtime, low latency & petabytes of data processing are few characteristics that have led to a world of services where the experience and expectations of a consumer have changed. In addition, the number of users has increased manifold and these users are always connected.

Organizations are looking for high service availability and also to innovate rapidly.

Reactive systems history

The traditional N-Tier, CRUD-based application design, simply does not address the challenges of this new reality. The architecture patterns, data processing, and scaling demands need a new approach of distributed systems to address these challenges.

To cater to such demands on the applications, enterprises have been adopting new architecture thinking, that:

  • Leverages distributed compute resources at scale
  • Is explicit about failures
  • Is inherently asynchronous and non-blocking
  • Removes all contentions from the systems aiming to leverage resilience and availability from such an approach.

Thus, modern enterprise systems are distributed from the ground up. Operating services in a distributed architecture is a challenge and opportunity both. Bringing all the features of this new architecture paradigm into a unified definition is Reactive Manifesto. Reactive manifesto underlines the traits of Responsive, Resilience, Elastic, Message Driven in a reactive system.

Reactive — Reacts to What?

Responsive: React to User. The system should provide consistent response times and quality of service.

Elastic: Reacts to load. The system should stay respond under varying workloads

Resilient: Reacts to failures. the system should stay response in event of failures

Message-Driven: Reacts to Messages. The system should establish asynchronous message passing.

Reactive architecture embraces the inherent nature of distributed systems i.e.

  • Unreliability of network,
  • Latency of data across the network,
  • Failures in parts of systems,
  • Eventual consistency of data

This nature of distributed systems was presented as a set of “fallacies” in a 1994 Sun Microsystems paper — Fallacies of Distributed Computing.

Traditional architectures attempted to hide these fallacies with patterns like 2PC XA/Distributed Transactions, WS-Coordination, Other WS-*, CORBA, etc. These patterns treated communication across services as if these were local method calls by disguising the network calls as method calls within JVM and making a big assumption that the network is always reliable. Reactive Systems are explicit about the network & failures and make them a part of the “flow”. In a distributed system like a microservice, there is no guarantee that the service being called is available or that the network would not fail or drop the messages. By being message-driven, such unreliability can be handled with greater flexibility than remote method invocations or distributed transactions.

The end value of reactive systems is Responsiveness, the ability of the application to be always efficiently available. Responsiveness is the cornerstone of usability.


Reactive

Terms and Definitions

Reactive Manifesto

The Reactive Manifesto was penned in 2013 to provide business leaders and technologists with a cohesive approach and common vocabulary to accelerate the evolution toward reactive systems. 

Reactive manifesto

Reactive Systems

  • Reactive Systems apply reactive principles at the architectural and systems levels. Principles mentioned in the reactive manifesto are the basis of the architecture of reactive systems.
  • Reactive Systems are decoupled asynchronously.
  • Reactive Systems, which result from adopting reactive architecture can benefit from a reactive programming model, although it is not a pre-requisite. But usage of reactive programming alone doesn’t mean Reactive architecture. Reactive systems imply reactive architecture based on reactive principles.
  • This makes them easier to develop and amenable to change. They are significantly more tolerant of failure and when failure does occur, they meet it with elegance rather than a disaster.
  • Example of Reactive System: Reactive Microservices.

Reactive Architecture

Can mean:

  • Any architecture that is a realization of reactive principles. It doesn’t assume stack or choice of the programming model.
  • Reactive principles Solution building blocks that enable development. For example, LightBend Akka toolkit and Lagom frameworks are meant for reactive architecture.
  • Reactive architecture applied across related components, services and applications turn the dials towards Reactive Systems

Reactive Programming

  • Reactive Programming is based on writing asynchronous non-blocking processing that efficiently uses the threads and CPU cores to reduce the wait/block state of threads, thus removing the CPU contention from threads.
  • Aims to leverage multicore CPU architecture instead of relying on the processor clock speed, which has reached a peak (Inverse of Moore’s Law)
  • The reactive frameworks provide a way for the programmers to deal with a threaded model that eliminates the need for thread waits. Constructs like Promise or a Future or Stream are used to handle the response that is available “sometime in future”.
  • The major specification on reactive programming models is Reactive Streams. This specification provides contracts to enable message stream processing in an async non-blocking fashion.
  • Reactive programming style is now new and has been around in various forms like event-listeners in swing and browser JavaScript DOM libraries
  • Reactor, RxJava / RxScala framework, Akka are examples of reactive programming tools.
  • Usage of a reactive programming model doesn’t automatically mean a reactive system or a reactive architecture.

Reactive Microservices

Developing microservices-based applications on reactive principles and programming model results in reactive microservices. Reactive Architecture and Microservices had evolved independently. Reactive principles can be applied to practically any kind of architecture and microservices can be developed in the traditional “sync-REST” style as well. But because both ideas are rooted in handling distributed services, the notions of consistency, availability, latency, time, scalability & time are common concerns to solve. Reactive microservices enables maximum leverage of an inherently distributed nature. Reactive microservices are one application of reactive architecture.

The message-driven aspect of the reactive manifesto is the pervasive driver in reactive microservices and fits right into the evolution of distributed microservices (from a monolith or to alleviate the distributed monolith problem).

Reactive microservice

It is possible that microservices are developed without any consideration for either reactive manifesto or reactive programming, but the maturity for such a microservices would be low

Reactive systems

Reactive Systems — Drivers and Value

microservice Architecture Reactive programming mobile app Data processing

Opinions expressed by DZone contributors are their own.

Related

  • Serverless Patterns: Web
  • How to Practically Implement Microservices Infrastructure in Your Business
  • Designing High-Volume Systems Using Event-Driven Architectures
  • Microservices Architecture: What, When, and How

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!