Stop testing, start deploying your AI apps. See how with MIT Technology Review’s latest research.
Download now
share
The data landscape has grown increasingly demanding and crowded in the last few years, with many platforms competing to offer the best processing and storage options. Tech consumers expect companies to deliver high-speed data processing while simultaneously offering a variety of adaptable solutions that work with traditional applications but also built for modern architecture like microservices.
Unlike a monolithic framework, a microservice structure enables companies to facilitate faster time-to-market for new applications or updates. With the lightweight design and agility of microservices, companies can allocate each individual service they offer to its own distinct database. But a monolithic framework does guarantee something that microservices might not: data consistency. When adopting a microservice architecture, it is important to consider how microservices share data between them, in order to prevent any particular service from creating a bottleneck and collapsing the whole system.
This is where Redis Enterprise comes in. Redis Enterprise is built over open-source Redis, and is a CRDTs (conflict-free replicated data types) based, active-active database. Redis Enterprise offers companies two options for data synchronization: They can either share datasets across microservices, or transfer data between them.
In the former case, a company can share datasets across microservices by relying on Redis Enterprise’s functionality as a conflict-free database. Redis CRDTs account for the possibility of multiple instances of a microservice by allowing each microservice to connect to the local instance of a distributed Redis Enterprise database. This CRDT technology ensures strong eventual consistency, which means that all data replicas will eventually achieve the same consistent state across all microservices.
The other option companies have is to create an event based architecture for microservices. Redis Enterprise offers multiple ways to do this — Pub/Sub, Lists, Sorted Sets or Streams. The Pub/Sub implementation employs a simple and memory-efficient form of asynchronous communication, which requires subscribers to be active in order to receive data. The Lists data structure, meanwhile, supports a blocking call for an asynchronous data transfer, and is particularly efficient because it persists data even if a receiving microservice fails.
The third technique, Sorted Sets, is ideal for transferring time-series data, but unlike Pub/Sub and Lists, it does not support asynchronous data transfers. Although Pub/Sub, Lists and Sorted Sets all offer viable ways to transfer data, Streams is effectively the culmination of the other three methods because it combines all their benefits while also supporting connectors for multiple clients and staying resilient to connection loss.
Given all of these options for companies to ensure data consistency across microservices, if you were to ask me I would no doubt say that Redis Enterprise is the ideal database solution for any microservice architecture. Redis Enterprise is highly available and durable, offers multi-tenant and Kubernetes support, provides both cloud and on-premises options and — perhaps most importantly — is extremely easy to use. However, you don’t have to take my word for it. Sign up for a free Redis Enterprise database for free and try it out for yourself or read more in our documentation.
If you still have any questions about how you can operationalize your microservice offerings with Redis Enterprise, or about how to achieve data consistency across your microservices, please don’t hesitate to contact us at product@redis.com.
