So, to build an entirely reactive application, we need a repository that operates not with collections of entities, but rather a repository that operates with reactive streams of entities. A reactive repository should be able to save, update, or delete entities by consuming not only an Entity itself but also by consuming a reactive Publisher<Entity>. It should also return data through reactive types. Ideally, when querying the database, we would like to operate with data repositories in a similar way to WebClient in the Spring WebFlux module. Indeed, the Spring Data Commons module provides the ReactiveCrudRepository interface with such a contract.

Now, let's discuss what benefits we may expect when using a reactive data access layer instead of a usual blocking one. Chapter 3, Reactive Streams - the New Streams' Standard, compares synchronous and reactive models of data retrieval, so, by employing an ideal reactive data access layer, our application may receive all of the following benefits:

• Effective thread management, since no thread is required to ever block on IO operations. This usually means that fewer threads are created, there's less overhead on thread scheduling, there's less memory footprint allocated for the Thread object's stack, and consequently, it's able to handle a massive amount of concurrent connections.
• Smaller latency to the first results of a query. These may become available even before the query finishes. It may be convenient for search engines and interactive UI components that target low latency operation.
• Lower memory footprint. This is useful as less data is required to be buffered when processing a query for outgoing or incoming traffic. Also, the client may unsubscribe from a reactive stream and reduce the amount of data sent over the network as soon as it has enough data to fulfill its needs.
• Backpressure propagation informs the client about a database's ability to consume new data. Also, it permits informing the database server about the client's ability to process query results. In this case, more urgent work may be done instead.
• One more benefit may come from the fact that reactive clients are not thread bound, so sending a query and different data processing operations may happen in different threads. In turn, underlying queries and connection objects have to be tolerant to such modes of operation. As no threads hold exclusive rights over query objects and no client code is ever blocked, it is possible to share a single wire connection to the database and forget about connection pooling. If a database supports a smart connection mode, query results may be transported via a single physical network connection and routed to correct reactive subscribers.
• Last but not least, smooth integration of the persistence layer with a fluent reactive code of the reactive application is backed by the Reactive Streams specification.

The more reactive a database access stack is, the more benefits an application may have. However, it is possible to gain some of the benefits mentioned previously by applying an asynchronous driver or even a blocking driver wrapped into a proper reactive adapter. An application may lose its ability to propagate backpressure, but it still may use less memory and have proper thread management. Now, it is time to play with a reactive code in a Spring Boot application.

To enable reactive persistence in a Spring Boot application, we have to use one of the databases that have reactive connectors. At the time of writing, the Spring Data project provides reactive connectivity for MongoDB, Cassandra, Redis, and Couchbase. This list may seem to be limited, but at the moment the reactive persistence is still a novelty headed towards widespread acceptance. Plus, the primary constraining factor that limits the Spring team in reactively supporting more databases is a lack of reactive and asynchronous drivers for databases. Now, let's investigate how a reactive CRUD repository works in the example of MongoDB.