There are some key aspects of the reactive principles applied to microservices. Although these should be part of microservices in general, but they are more highlighted in the context of reactive microservices to do away with the prior pitfalls we had with SOA frameworks and technologies.

• Isolation: Isolation between microservices is to limit them as if each is running in its own sandbox process. These microservices should be isolated not just between various microservices, but also between the multiple instances of the same microservice as well. The isolation should be failure protective in the sense that failure in one service should not affect the processing of another instance or other running microservices, and should be easily replaceable by other instances.
• Autonomous: A reactive microservice should be autonomous as much as possible, which means that it should expose its interface and behavior and fulfill it without external factors. The microservice should have support for a self-healing mechanism internally, or as a standard in the microservices-based architecture. Autonomous services enable flexibility for service orchestration and collaboration as well as scalability, availability, and runtime manageability.
• Single responsibility principle (SRP): A component should have only one reason to change. This, in other words, also means that a component should do one thing and do it well. When a microservice has a single reason to fulfill, it simplifies both the business process and the technical implementation associated with it, which allows it to be autonomous as well.
• Statelessness: The best reactive microservices are stateless as much as possible. There are certain circumstances that require the state to be shared amongst microservices; it should be limited where applicable. The data should be segregated between different microservices, and this can be split using DDD's bounded context technique as described previously. An effective and quick way, which could be applied to certain types of data persistence for the state of microservices, is known as Event Sourcing. With this, we capture the state change of an object as a new row of an event to be stored in the Event Log. It is a way of persisting the application's state by storing the history, which ultimately determines the current state of your application.
• Asynchronous messaging: Asynchronous communication enables non-blocking execution of the code, which results in efficient use of computing, storage, and communication resources. Asynchronous messaging and event-based models for a service allow the services to be dynamic and easily scalable by adding the number of instances consuming the events coming up at a rate over a message queue. Having a message queue allows multiple consumers or multiple instances of the same microservices to process in parallel--this not only uses the resources efficiently, but also responds quickly enabling better usability experience. Reactive microservices architecture is not in favor of REST-based HTTP services, as these usually imply synchronous communication, and do not ensure loose coupling between producers and consumers. It is recommended to use the usual REST communication only where there are only a couple of microservices communicating together in a tight (business and technical) coupling scenario.
• Mobility: When microservices are isolated and autonomous with a single responsibility, they are also better as mobile as possible. This means you can shift services from one physical location to another or add more instances of services, but the client is not affected and gets a consistent response in a timely manner. This is also called location transparency. Here, reactive microservices should not only be location transparent, but should be virtually addressable so that each microservice is reachable and replaceable effectively. Mobility of services is achievable rather easily once the asynchronous messaging patterns are in place.