In a microservices software architecture, 90% of the problems relate to data management between services.
In this post we see the summary of one of the design patterns that concern these issues: the database for service design pattern.
In the previous example we’ve tested with ApacheBench an application deployed using Kubernetes and Docker, composed by a Node.js microservice to get and set key value pairs on Redis.
We saw that if we have many concurrent requests from multiple clients we can’t know before which will be the final value of the key on Redis.
In this post we see an example about how we can lock a key value pair on Redis, so that another client has to wait before to set a new value.
We will use the Node.js implementation of Redlock, the algorithm to have distributed locks with Redis.
In the previous example we have seen how to use Kubernetes and Docker to deploy a Node.js microservice to interact with Redis, also showing in a basic way how Redis persistence works and how to scale up application’s microservice.
In this example we will test our application using ApacheBench.
This will show the applications behaviour when we have many requests and what happens in case of high concurrency with Redis.