The source code for this post is available on GitHub.

One of the nice things about a reactive programming model is there is a significantly lower risk of doomsday when things start getting latent all at once. You don’t have threads upstream blocking and waiting for a response, therefore they won’t all seize up and stop serving requests [or they won’t short circuit if you’re using a resiliency library like hystrix].

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.

The source code for this post can be found on Github.

Mock Server is a really simple and straightforward way to actually let your application make downstream calls and intercept them. That level of abstraction is really nice to have, and gives at least me much more confidence that my code is actually working in a microservices environment.

The source code for this post can be found on Github.

The most straightforward way to write unit tests in spring boot webflux is to leverage project reactor’s StepVerifier. StepVerifier allows you to pull each item in a Flux or the only potential item in a Mono and make assertions about each item as it’s pulled through the chain, or make assertions about certain errors that should be thrown in the process. I’m going to quickly walk you through an example integrating mockito with it and webflux.

The OpenAPI Specification is an “industry standard” way of declaring the API interface. As REST APIs using JSON have dominated the way we move data around in most organizations and on the internet, particularly in service oriented architectures, and as documentation at almost every company has been written once, read a couple of times, then lost to the wind, smart people have figured out that they can put the documentation for their services living with the code–better yet, displayed while the app is running.

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.

Optimistic Locking is a compromise to improve performance. If processors were infinitely fast, we wouldn’t need it and it would add unnecessary complexity. But, well, they aren’t.

The source code for this post can be found on Github.

When you make the switch to a reactive codebase, ThreadLocal becomes effectively off limits to you, because you aren’t guaranteed that the thread that starts the request processing remains the same, even if it’s the same HTTP request. This has caused pain in many places: the original implementation of spring security, for example, relied very heavily on ThreadLocal variables to store state that happened in the start of the request, and then reuse the information stored in those variables later on to make access control decisions. Neflix spoke of their pain migrating to a reactive stack, when they had relied so heavily on ThreadLocal variables in most of their shared libraries.

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.