As of this writing, there are a solid twenty or so commands you can execute against redis for the list data type. This article will be walking through some of the more common operations you are likely to need when interacting with redis and lists using lettuce, and the source code can be found on Github.
The source code for what follows can be found on Github.
There are, as of this writing, 27 different string operations available in the redis API. Lettuce appears to have interfaces that directly support all of them.
In clustered redis, any non hash tagged key can be sent unpredictably [well, actually predictably, if you know the formula] to any given primary node in the cluster. The very basic way it works is:
To follow along with this post, it would be best if you have already set up your local redis cluster and know how to connect to a redis cluster and interact with it via Lettuce. And the source code for what follows can be found on Github.
Lettuce has some pretty nice out of the box support for working with clustered redis. This combination–a reactive client and application along with clustered redis–is about as scalable, performant, and resilient as things can get in distributed systems [though there are other tradeoffs which are not the subject of this post].
The source code for this post can be found on Github.
Lettuce supports reading from redis replicas, but with the caveat that it doesn’t [out of the box] provide you with the fine-grained control over when to read from the replicas that you’re likely to want.
The source code for this post can be found on Github.
In a previous post, we detailed how to write integration tests for lettuce clients in spring boot webflux using a redis test container. That’s fine and well when you’re just writing code for a quick feedback loop, but is useless when it comes to running the application in real life. This post will start up redis locally and then explain how to best connect to it using lettuce in webflux.
The source code for this post can be found on Github.
Another way to write integration tests for code that verifies your interactions with redis actually make sense is to use a test container. This framework assumes you have docker up and running, but if you do it will pull a specified container image [typically you’ll just use docker hub, though it’s important to note that they rate limit you, so don’t go overboard], then you can interact with that container in your integration tests.
The source code for this article can be found on Github.
Lettuce is a redis client with reactive support. There is a super handy embedded redis for java project out there, and this kind of integration testing inside your service is worth its weight in gold, in my humble opinion. This post will detail how to merge both of these worlds together, and set up redis integration tests when you’re using a lettuce client.
A Reactor Mono comes with a lot of methods that allow you to do things when errors occur:
SNS is a medium to broadcast messages to multiple subscribers. A common use case is to have multiple SQS queues subscribing to the same SNS topic–this way, the publishing application only needs to focus on events that are specific to its business use case, and subscribing applications can configure an SQS queue and consume the event independently of other services. This helps organizations scale and significantly reduces the need to communicate between teams–each team can focus on its contract and business use case.
Sample code for this article can be found on Github.
In memory caching can significantly improve performance in a microservices environment, usually because of the tail latency involved in calling downstream services. Caching can also help with resilience, though the extent to which that matters will depend on how you’re actually leveraging that caching. There are two flavors of caching that you’re like to want to use, the first is using the Mono as a hot source [which is demonstrated here], and the second would be when you want to selectively cache individual key/value pairs.
