A DynamoDB Global Secondary Index is an eventually consistent way to efficiently query for data that is not normally found without a table scan. It has some similarities to Local Secondary Indexes, which we covered in the last post, but are more flexible than them because they can be created, updated, and deleted after the base table has been created, which is not true of Local Secondary Indexes.
DynamoDB’s Local Secondary Indexes allow for more query flexibility than a traditional partition and range key combination. They are also the only index in DynamoDB where a strongly consistent read can be requested [global secondary indexes, the other index that dynamo supports, can at best be eventually consistent]. I will walk through an example for how to use local secondary indexes in dynamo using the AWS SDK 2.0 for Java, which has full reactive support, in this post.
In this post, we’ll demonstrate how expiring items in DynamoDB works in java, using the AWS SDK 2.0+, which has full reactive support.
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.
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.
The source code for this post can be found on Github.
Intermittent network flapping, or any one downstream host of several clones responding slowly, is a not uncommon thing that happens in a microservices architecture, especially if you’re using java applications, where the JIT compiler can often make initial requests slower than they ought to be.
The source code for this post is available on Github.
Things break. When you start adding more and more microservices, things will break a lot more. This post is about how to provide a degraded experience to your users when things break.
The source code for this post can be found on Github.
Following up on the last post, which was making sequential calls to downstream services, sometimes you are in a position where you can make calls in parallel and merge the results. In this case, we want to use zip.
The source code for this article can be found on Github.
In reactive programming, it’s a game of callbacks. In the vast majority of cases, you will want to defer all of your I/O operations to the library you are using [typically, netty, under the hood], and stay focused on setting up the flow so that the right functions are invoked in the right order. Sometimes you will want to make calls in parallel, sometimes you need data from a previous call or operation available in order to invoke that right function.
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.
