# DynamoDB's Best Feature: Predictability

DevFeed: [DynamoDB's Best Feature: Predictability](<https://devfeed.tech/articles/dynamodb-s-best-feature-predictability-12514.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2022/01/19/predictability.html>)

Author: Marc Brooker

Published: 2022-01-19T00:00:00Z

Content type: opinion

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [NoSQL](<https://devfeed.tech/topics/nosql.md>), [Database](<https://devfeed.tech/topics/database.md>), [MySQL](<https://devfeed.tech/topics/mysql.md>), [Replication](<https://devfeed.tech/topics/replication.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [IO](<https://devfeed.tech/topics/io.md>), [Latency](<https://devfeed.tech/topics/latency.md>)

Tags: [amazon](<https://devfeed.tech/tags/amazon.md>), [cache](<https://devfeed.tech/tags/cache.md>), [database](<https://devfeed.tech/tags/database.md>), [io](<https://devfeed.tech/tags/io.md>), [latency](<https://devfeed.tech/tags/latency.md>), [mysql](<https://devfeed.tech/tags/mysql.md>), [replication](<https://devfeed.tech/tags/replication.md>)

## AI overview

The article argues that DynamoDB's most valuable feature is predictability under load. It contrasts DynamoDB's clean rejection of excess work with the latency spikes, contention, cache thrashing, and operational instability experienced in a MySQL-based system.

## Source excerpt

DynamoDB's Best Feature: Predictability Happy birthday! It's 10 years since the launch of DynamoDB, Amazon's fast, scalable, NoSQL database. Back when DynamoDB launched, I was leading the team rethinking the control plane of EBS. At the time, we had a large number of manually-administered MySQL replication trees, which were giving us a lot of operational pain. Writes went to a single primary, and reads came from replicas, with lots of eventual consistency and weird anomalies in the mix. Our code, based on an in-house framework, was also hard to work with. We weren't happy with our operational performance, or our ability to deliver features and improvements. Something had to change. We thought a lot about how to use MySQL better, and in the end settled on ditching it entirely. We rebuilt the whole thing, from the ground up, using DynamoDB. At the time my main attraction to DynamoDB was somebody else gets paged for this, with a side order of it's fast and consistent. DynamoDB turned out to be the right choice, but not only for those reasons. To understand the real value of DynamoDB, I needed to think more deeply about one of the reasons the existing system was painful. It wasn't just the busywork of DB operations, and it wasn't just the eventual consistency. The biggest pain point was behavior under load. A little bit of unexpected traffic and things went downhill fast. Like this: Our system had two stable modes (see my posts on metastability and on cache behavior): one where it was ticking along nicely, and one where it had collapsed under load and wasn't able to make progress. That collapsing under load was primarily driven by the database itself, with buffer/cache thrashing and IO contention the biggest drivers, but that wasn't the real cause. The real cause was that we couldn't reject work well enough to avoid entering that mode. Once we knew - based on queue lengths or latency or other output signals - the badness had already started. The unexpectedly expensive w