When we start to build microservice architecture, we try to involve different services to deliver business solutions. We often build services as traditional API models, where each of the services can interact with other services. This is referred to as distributed architecture. If a distributed architecture is designed incorrectly, performance issues surface very quickly. It can be difficult to have numerous distributed services that work concurrently to deliver the intended performance. Companies that offer services requiring large data exchange (such as Netflix, Amazon, or Lightbend) have therefore seen a need for alternative paradigms, which can be used for systems with the following characteristics:

• Consisting of very loosely coupled components
• Responding to user inputs
• Resilient to varying load conditions
• Always available

In order to achieve the preceding characteristics, we need to build event-driven, modular services that communicate with each other by using notifications. In turn, we can respond to the system's flow of events. The modular services are more scalable, as we can add or remove service instances without halting the complete application. The complete architecture will be fault tolerant if we can isolate errors and take corrective actions. The preceding four characteristics are the basic principles of the Reactive Manifesto. The Reactive Manifesto states that each reactive system should consist of loosely coupled components that rely on asynchronous, message-driven architecture. They must remain responsive to user input and isolate failures to individual components. Replication must be done in order to respond to varying load conditions. The following is a diagram of the Reactive Manifesto:

The Reactive Manifesto describes a reactive system. It does not required that the system be based on reactive programming, or any other reactive library. We can build a message-driven, resilient, scalable, and responsive application without using a reactive library, but it is easier to build an application based on reactive libraries.

Most of us write imperative applications, where statements are required in order to change the application state. The code is executed and a final state is arrived at. After the state's computation, the state does not change when the underlying factors do. Let's consider the following code as an example:

int value1 = 5;
int value2 = 10;
int sum = val1 + val2;
System.out.println(sum); // 15
value1 = 15;
System.out.println(sum); // 15

The sum is still 15, even though value1 has been changed.

On the other hand, reactive programming is about the propagation of change. It is also referred to as declarative programming, where we express our intent and application state as dynamically determined by changes to underlying factors. The preceding sum program example, under a reactive paradigm, would behave as follows:

int value1 = 5;
int value2 = 10;
int sum = val1 + val2;
System.out.println(sum); // 15
value1 = 15;
System.out.println(sum); // 25

Consequently, if a program reacts to changes in the underlying factors, it can be called reactive. Reactive programs can be built using imperative techniques, like callbacks. This may be fine for a program that has a single event. However, for applications where hundreds of events are happening, this could easily lead to callback hell; we could have numerous callbacks relying on one another, and it would be really difficult to figure out which ones were being executed. As a result, we require a new set of abstractions that enable us to seamlessly build asynchronous, event-driven interactions across a network boundary. There are libraries in different imperative languages, like Java, that provide us with these abstractions. These libraries are referred to as Reactive Extensions.