The source code for this article can be found on Github.
The Resilience4j circuit breaker by default considers any exception thrown inside of the Supplier as a failure. If over 50% of the calls are failures and the rolling window max size is met, then it will prevent any future calls from going through.
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.
When you’re working with distributed systems, it is often the case that some clones of a service running can be slow to respond, while still others are functioning perfectly normally. Therefore, when you just hit a load balancer and the load balancer chooses a backend, it can sometimes be beneficial to retry the request. Other things like periodic and small database stalls or random GC stop-the-worlds are examples where retries can smooth the experience for the client of your service.
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.
The source code for this article can be found on Github.
Redis streams are an interesting data structure that act as a sort of go-between for list and pub/sub operations: It’s like a list in the sense that anything pushed onto the stream is retained, it’s like pub/sub in the sense that multiple consumers can see what is happening to it. There are many other features of streams that are covered in that article, but that’s at least how you can think of it at the start.
The source code for this article can be found on Github.
Using Redis as a best effort locking mechanism can be very useful in practice, to prevent two logical threads from clobbering each other. While redis locking is certainly not perfect, and you shouldn’t use redis locking if the underlying operation can’t be occasionally done twice, it can still be useful for that “best effort, do this once” use case.
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.
The source code for what follows can be found on github.
In a previous article, we showed how to efficiently execute a lua script in redis using lettuce. To really scale our caching solution horizontally [and elegantly deal with many scaling headaches], we will also want to make sure we can execute our lua scripts against clustered redis, which as we’ll see here is pretty straightforward.
The source code for what follows can be found on Github.
Optimistic Locking in Redis is one of the only reasons to want to use transactions, in my opinion. You can ensure a grouping of atomic operations only occur if a watched key does not change out from underneath you. On the CLI, this might start with:
The source code for what follows can be found on Github.
Redis Transactions do not operate exactly the way you would expect if you’re coming from a relational database management system like MySQL or postrgres. It’s mostly useful for optimistic locking, but honestly there are better ways to accomplish many of the things you’re probably trying to, like running a lua script with arguments [which is guaranteed to be atomic]. The documentation on transactions in redis describes some of the caveats, the biggest one probably being that it does not support rollbacks, only commits or discards.
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.
