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.

When you update an item in DynamoDB, you can optionally update the item in place. That is, instead of read-increment-write, you can just issue a command that says increment this value in place. This behavior is detailed in the AWS documentation, and I will provide an example for how to do so with the Java AWS SDK 2.0, which has full reactive support.

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:

Leveraging Mono.zip appropriately will [with the right configuration] lead to a high amount of performance and concurrency. There is one caveat to its usage though:

There’s a very insidious bug that can happen when you’re writing reactive code, and it basically comes down to whether an underlying Mono in a chain of operations was actually subscribed to, rather than merely observing a method invocation. I’ll demonstrate with an example.

DynamoDB transactions can be used for atomic updates. Atomic updates in DynamoDB without transactions can be difficult to implement–you’ll often have to manage the current state of the update yourself in something like a saga, and have business logic specific rollback procedures. Further, without a transaction manager, the data will be in an inconsistent state at some point in time while the saga is ongoing. An alternative to that is a Two Phase Commit, but that’s also expensive both from the standpoint of developers making it work as well as performance [2PC typically call for a lock being held during the operation, and even then there’s a possibility that the operation ends up in an inconsistent state at some point].

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.

Nested attributes in DynamoDB are a way to group data within an item together. The attributes are said to be nested if they are embedded within another attribute.

Scanning in DynamoDB is exactly what it sounds like: loop through every single record in a table, optionally filtering for items with a certain condition when dynamo returns them to you. In general, you shouldn’t do this. DynamoDB is designed to store and manage a very large amount of data. Scanning through a large amount of data is very expensive, even in a distributed world. In the best case, you’ll be waiting a long time to see results. In the worst case, you might see service outages as you burn through your RCUs.

If there’s something in the documentation about what the behavior of a DynamoDB Global Secondary Index is when there are duplicate keys in the index, it isn’t easy to find. I tested this empirically with an embedded DynamoDB mock for java and will quickly share my findings here with you.