Skip to main content

How UFO protected from DynamoDB outages

Context - The October 21 2025 AWS Outage 

I've just read a news article about Amazon Web Services (AWS) having a problem with their DynamoDB service which impacted a lot of their customers in the popular / vital US-EAST-1 region. This reminded me of another time that relying on DynamoDB caused an outage for one of the companies that I was working for when I lived in London, and how we went about preventing that from happening again.

"It's always DNS"

"Based on our investigation, the issue appears to be related to DNS resolution of the DynamoDB API endpoint in US-EAST-1." 

It's a cliché that outages on the Internet are often caused by some issue involving DNS, that happened to match up with the root cause this time around.

What's the UFO?

My team's core service was for capturing metadata about customers' usage of various components of the website. Because the service relied on DynamoDB for storing that information, we came up with a fallback service for the rare situations of DynamoDB being unavailable for any reason. At the time we were using short names for our services, typically based on the acronym of the service name - so I retro-fitted a service name to match with UFO as acronym, Usage Fallback Option.

How did it work?

The UFO service would write to an alternative data store that was independent of DynamoDB.

Clients of the normal usage service applied a circuit-breaker approach to interactions with the regular usage service, so the fallback service would automatically start to receive traffic if an outage occurred. 

Recovery scripts were available for either re-feeding the data into DynamoDB once it came back into service, or for progressing to the next phase of the data processing pipeline.

Should this approach be broadly applicable?

The short answer is "No."

In this particular situation we had a piece of functionality that was not visible to customers and was just an implementation detail of an asynchronous data procsesing pipeline.

On other projects I have worked on services that relied on DynamoDB as the primary data source involved in serving content on a website, so there was no similar fallback mechanism available there. Caches could have hidden some of the outage, but they were not intended to keep the site up.

It made sense to invest in the fallback service for usage as usage data acted as the transaction measurement of value being delivered when it came to contract negotiations with customers.

As the most recent outage only impacted a single region, I expect that the team would have been able to switch traffic to 0% in the impacted region. This would have been possible due to the regions being structures to be fully independent.

Addendum

Blast radius

From a brief skim-read of the AWS status page it is apparent that EC2 launching had a dependency on DynamoDB, I take that to imply that the UFO service would not have been able to scale up to pick up the full load of usage events.

Comments

Popular posts from this blog

2022 - A year in review

Just a look back over the last 12 months. January I moved back to Christchurch to live, after having spent a few months further south since moving back from London. Work was mainly around balancing other peoples' understanding and expectations around our use of Kafka. February I decided that it would be worthwhile to have a year's subscription for streaming Sky Sports, as some rugby matches that I would want to watch would be on at time when venues wouldn't be open. Having moved to Christchurch to be close to an office, now found myself working from home as Covid restrictions came back into effect across New Zealand. March Got back into some actual coding at work - as opposed to mainly reviewing pull requests for configuration changes for Kafka topics.  This became urgent, as the command line interface tool that our provisioning system was dependent on had been marked for deprecation. April   Had my first direct experience with Covid-19.  I only went for a test because ...

Speeding up Software Builds for Continuous Integration

Downloading the Internet Can you remember the last time you started out on a clean development environment and ran the build of some software using Maven or Gradle for dependency management? It takes ages to download all of the necessary third party libraries from one or more remote repositories, leading to expressions like, "Just waiting for Maven to download the Internet". Once your development environment has been used for building a few projects the range of dependencies that will need to be downloaded for other builds reduces down as the previously referenced ones will now be cached and found locally on your computer's hard drive. What happens on the Continuous Integration environment? Now consider what goes on when Jenkins or your other preferred Continuous Integration server comes to build your software. If it doesn't have a local copy of the libraries that have been referenced then it is going to pay the cost of that slow " download the Internet" p...

Applying AI to software development can be like following SatNav

Trying out a different navigation system A month or so ago I upgraded to a car that has a SatNav system included, so I have been trying to use that instead of the Maps app on my phone. My experiences with it so far have generally been good, but it is far from flawless - a bit like Artificial Intelligence (AI) in software development. As context, my previous vehicle was not too old to include SatNav, it just hadn't been set up with English language or New Zealand maps - one of the down sides of having a second hand vehicle that originated in Japan. Flawed or incomplete information Driving around central Christchurch can be a bit challenging at times as various roadworks are underway, leaving streets closed off or narrowed down to a single lane. It could be reasonable to expect that a basic navigation system might not have up to the minute awareness of those closures and restrictions. However, something that I did not expect to encounter was the navigation system advising me to expec...