Querying DynamoDB in Java with the AWS SDK 2.0
Queries in DynamoDB allow you to find data. This is only an option to you if your table has a partition and sort key.
Queries in DynamoDB allow you to find data. This is only an option to you if your table has a partition and sort key.
I’ve previously written about using conditional expressions to achieve optimistic locking in DynamoDB, that example used the command line. I will now demonstrate how to do the same thing in java code, leveraging the AWS SDK 2.0 [with full reactive support].
While using the AWS SDK 2.0, which has support for reactive programming, it became clear that there was no straightforward support for an embedded dynamo db instance for testing. I spent a fair amount of time figuring it out by starting with this github link and ultimately adapting it to my own needs.
The source code for this post can be found on Github.
Following up on the previous post where we showed how to send SQS messages to Localstack using the AWS SDK for Java 2.0, we will now demonstrate how to write code that continuously polls for SQS messages, processes them, then deletes them off the queue.
The source code for this post can be found on Github.
The completely rewritten AWS SDK for Java 2.0 comes with full reactive programming support all the way down. I wanted a way to test it out without spending any more or being at risk of spending too much money, so I used localstack. This post is largely walking you through what I came up with.
Amazon SNS is AWS’s solution to pub/sub. In a large, distributed system, decoupling events from services that need to act on those events allows for teams that own different services to better work in parallel, and also prevents the need for coordinating code deploys to deliver new features. If a services is already publishing a generic event, other services can hook into that event and act on them without needing anything but a bit of infrastructure.
Optimistic Locking is a form of concurrency control that basically aims to prevent two different threads from accidentally overwriting data that another thread has already written. I covered optimistic locking in MySQL in a previous blog post, which may or may not be easier to understand based on your background.
DynamoDB Streams is AWS’s home grown Change Data Capture [CDC] mechanism, which allows the consumer of the stream to see records probably in approximately the order they were created [it’s basically impossible, at scale, to guarantee that all records across all partitions will somehow stream the data in exactly the same order that it was written]. This is a pretty fantastic feature because it allows us to reliably do —something— after we add new data, update existing data, or delete existing data. As long as all the stream records are read and processed, we can ensure at least once processing on data changes and then go sleep soundly at night knowing that there is one less edge case in our application. Combine that with the natural scale that DynamoDB provides via its leaderless architecture and you can build this thing once and probably never have to worry about it handling more load ever again.
In my last post on getting started with spring boot webflux and AWS DynamoDB, I mentioned that it wasn’t immediately obvious to find a way to customize the response code in a spring boot RestController, so I opted to use handlers instead.
The source code for this post can be found on Github.
The latest AWS SDK for java uses a reactive client to send requests to various AWS services, including DynamoDB. Reactive programming is ultimately more robust at the edges–once you start experiencing latency anywhere in your stack, if your tech is not reactive, you’re going to have a significantly worse time than if it were.
DynamoDB is a fully managed distributed datastore that does a great job of alleviating the operational overhead of building very scalable systems.