The source code for what follows can be found on Github.

The circuit breaker pattern, popularized by Netflix [using Hystrix], exists for a couple of reasons, the most prominent being that it reduces load on a downstream service when it is not responding properly [presumably because it’s under duress]. By wrapping operations that might fail and get overloaded in a circuit breaker, we can prematurely prevent cascading failure and stop overloading those services.

The source code for what follows can be found on Github.

Very often, you will want to test service api clients using a Mock Server [for example, testing the spring webclient with mockserver]. And since network latency is a fact of life, not something we can merely ignore, actually injecting some latency to simulate timeouts will give us greater confidence that our system will behave as expected.

We already know how to subscribe to redis using lettuce when it’s not running in clustered mode. If it’s running in clustered mode, it’s not terribly different, but I did discover one thing that is interesting, which is the subject of this article.

I have been playing around with test containers lately [ redis test containers for testing lettuce and dynamodb test containers for testing the AWS SDK 2.0, to be specific], and I found soon after using them that I was getting by default a stream of DEBUG level logs whenever I ran my test suite. This was annoying, so I went digging for a solution.

The source code for what follows can be found on Github.

Pub/Sub in redis allows a publisher to send things to subscribers without knowing who is actually subscribed. In a previous post, we covered a simple unit test for publishing and subscribing to lettuce, but if you want to have a subscription initialized on application startup, and respond to events, we’ll have to do a bit more, which I’ll demonstrate here.

The source code for what follows can be found on Github.

In my last article on running a lua script against redis with lettuce, we just sent the entire script [that redis will execute atomically] along with the arguments every time. For very small scripts this is unlikely to be a problem, but there is definitely a more efficient way to do this, using EVALSHA.

The source code for what follows can be found on Github.

Running a lua script against redis is done using EVAL. The primary benefit of using a lua script is that the entire script is guaranteed to be run at once, and nothing else will interfere with it [it’s atomic]. This allows for operating on multiple keys, or check-then-set type operations on the same key.

The source code for what follows can be found on Github.

Subscribing to topics in redis allows for a fanout behavior, where any number of subscribers can be notified of a message from a publisher.

Sorted Sets in redis are one of my personal favorite tools when operating at scale. As of this writing, there are over 30 unique operations you can perform against sorted sets in redis. This article will focus on some of the more common ones you’re going to need to know, and it will use a reactive lettuce client to demonstrate them.

In the last article, we showed how to do some of the most common single set operations against redis, this article will focus on operating on multiple sets using a lettuce client against redis. Specifically, we’ll focus on subtracting, intersecting, and adding sets. The source code for what follows can be found on Github.

There are, as of this writing, about 15 distinct operations available to someone wanting to work with sets in redis. This article seeks to cover some of the more basic ones using a reactive lettuce client, and a follow up article will seek to deal with explaining some of the more common operations against multiple sets, rather than a single set in this case.

There are about 15 or so commands you can execute against redis for hash types as of this writing. This article will demonstrate some of the more common operations you’re likely to need when using lettuce as your client.