Before DynamoDB, there was Dynamo.

More than a decade before DynamoDB powered apps like Zoom, Dropbox, Snapchat, and Tinder, a small team inside Amazon was trying to solve one big problem.

How to keep Amazon.com online when everything starts breaking?

It was about survival.

In the early 2000s, Amazon’s business was growing fast with more customers, more orders, more data, and more stress on its systems.

When you add something to your shopping cart on Amazon, you expect it to just work.

But back then, that simple click was a huge engineering challenge.

Databases that once worked fine were suddenly struggling to keep up.

On normal days, they were slow.

During peak shopping seasons, they broke.

And one winter, they really broke.

For Amazon, that was not acceptable.

This article tells the story of how DynamoDB was born.

Disclaimer: This post reflects what I have learned from various sources online, primarily AWS official sites. While I have made every effort to ensure accuracy, some information may not be completely precise.

The Outage That Started Everything

In December 2004, Amazon.com went down for several hours during the peak holiday shopping season.

It was not just a technical glitch, but a major business failure.

For an online store during the busiest time of the year, every minute of downtime meant lost sales, unhappy customers, and broken trust.

When the outage was finally over and the site was back online, Amazon engineers did something that many companies ignore.

They sat down and wrote a brutally honest report about what went wrong and why.

The Investigation Results

They wrote what they called a Correction of Error (COE) document.

It was a technical postmortem of the failure that used the five whys method, asking why again and again until they found the real reason.

The shocking discovery was this:

• 70% of database operations were simple single key lookups, like Get user's shopping cart.

• 20% were multi key operations within the same table, such as Get all items in this order.

• 90% of all database activity had nothing to do with relational capabilities.

Technically, they were using a Formula One race car to deliver pizza.

Then they faced a key question:

Why are we using a relational database for workloads that do not need relations?

The workloads were simple and repetitive:

• Shopping cart operations

• Session state management

• Location tracking

• Player state retrieval

These operations needed fast and reliable key value storage, not complex SQL queries, joins, or multi table transactions.

But that failure sparked one of the most important database innovations in history.

Connect with the author on LinkedIn for insights on cloud architecture.

The Dynamo Paper

In 2007, Amazon published a white paper called Dynamo: Amazon’s Highly Available Key-Value Store at the SOSP conference.

It was not just another research paper.

It was real, proven technology that Amazon had already built and used in production for years.

The paper explained how Dynamo kept Amazon’s core services running even when parts of the system failed.

Dynamo focused on a few simple but powerful ideas:

High Availability Over Consistency

In databases, high availability often comes as a trade-off with consistency. Dynamo chose to focus on availability.

Dynamo was an eventually consistent key value store designed for availability and fault tolerance rather than strict consistency.

Each piece of data was stored on three separate servers located in three different data centers to ensure durability and continuous access.

This design made Amazon’s shopping cart always available, even when some servers were down or disconnected.

Always Writeable

In traditional databases, a write can fail if part of the system is down. Dynamo was built to be always writeable.

Every write operation was stored on multiple replicas.

When a customer added an item to the cart, Dynamo did not wait for all three servers to confirm the update.

As soon as any two out of three servers acknowledged the write, it was accepted. The third server synced up later in the background, a method known as accept now, fix later(sloppy quorum).

This approach ensured that customer operations, such as adding or updating a shopping cart, continued to work smoothly even during server or network problems.

Simple Query Model

Dynamo kept the query model extremely simple.

It only supported operations by primary key with no joins or complex SQL queries.

Each item was stored as a binary object (blob) that could be retrieved using its key.

This simplicity allowed Dynamo to scale horizontally and deliver predictable performance even under heavy load.

Achieved Results

All these design choices led to impressive real-world results:

• 99.9995% successful response rate

• Zero data loss events reported

• Shopping Cart Service: Tens of millions of requests, 3+ million checkouts in a single day

• Scalable during busy shopping seasons without downtime

The system that was born from failure became Amazon’s secret weapon.

SimpleDB: AWS’ First NoSQL Database

While Amazon was improving its internal Dynamo system, the team realized something important.

External customers might be facing the same challenges. Many companies were struggling with complex MySQL setups just to handle simple primary key lookups.

Amazon had already solved this problem internally.

So, in the same year the Dynamo paper was published, AWS launched SimpleDB, its first public NoSQL database service.

It was revolutionary at the time. Customers loved it because there was no need for server management.

It offered a flexible data model, high availability, and a simple interface.

However, over time, customers started reporting its limitations.

Each domain was limited to 10 GB of storage, which forced users to split data across multiple domains.

Performance was sometimes unpredictable because SimpleDB automatically indexed all attributes, which slowed down writes and increased memory usage.

Pricing was also complex and difficult to estimate.

Even with these challenges, SimpleDB was a valuable experiment.

It helped AWS learn what customers really wanted: simplicity, scalability, and a fully managed service without strict limits.

Today, SimpleDB is considered deprecated, although AWS has never officially announced it.

DynamoDB: The Next Evolution

After years of running Dynamo inside Amazon and learning from the challenges of SimpleDB, AWS decided to build something new.

In 2012, AWS launched DynamoDB, a NoSQL database designed for speed, scalability, and zero operational burden.

It is important to note that Dynamo (2007) and DynamoDB (2012) are completely separate systems.

They share the same design principles but have very different implementations.

DynamoDB was built as a distributed hash table with a few key requirements:

• Partitionable from the beginning: It needed to scale down to individual items without using add-on sharding.

• Horizontal scaling: Every part of the system had to scale evenly to prevent bottlenecks.

• Multi-tenant architecture: Resources had to be shared efficiently while keeping data isolated.

• Zero downtime: The system had to keep running continuously without planned maintenance interruptions.

Scaling and Performance Milestones

According to AWS documentation, DynamoDB has reached remarkable scale and reliability:

• Handles trillions of requests per day

• Used by major companies such as Netflix, Disney Plus, and Samsung

• Tables can scale to petabytes of data

• Delivers single-digit millisecond latency for reads and writes

Recent Inovation

AWS has made several improvements to DynamoDB up to 2024.

The price of on demand capacity mode was reduced by 50 percent. This change reflects DynamoDB’s growing adoption and AWS’s effort to pass those savings back to customers.

The extra cost for Global Tables regional writes has been removed. Writing to multiple regions now costs the same as a replicated write in one region.

A new feature called Warm Throughput provides better visibility into how tables use resources. It helps users understand performance more clearly and gives the experience of dedicated capacity even in a shared system.

Integration has also improved. DynamoDB now supports direct connections with OpenSearch, Redshift, and S3 without complex ETL steps.

Security has been strengthened with resource based policies, PrivateLink support, and attribute based access control.

Operationally, DynamoDB Accelerator (DAX) now delivers microsecond latency for even faster response times.

Now, it serves as a tier zero dependency within Amazon, meaning many other AWS services such as EC2 and Lambda now directly depend on it.

If DynamoDB fails, several critical AWS services would be affected. For example, the outage on October 20, 2025.

Key Lessons from DynamoDB’s Evolution

Two decades after Amazon’s 2004 holiday outage, DynamoDB’s journey from failure to one of the most reliable databases offers lasting lessons.

Innovation often starts with failure.

When most companies were focused on relational databases, Amazon asked a simple question: why? That question opened the door to a new way of thinking about scale and reliability.

Prove before publishing.

DynamoDB was tested in production for years before the paper was shared, ensuring it was trusted and practical.

Internal tools can become global standards.

A solution for Amazon’s challenges now powers thousands of systems worldwide.

Simplicity wins.

DynamoDB’s focus has always been on making complex systems simple, reliable, and easy to use.

This story shows that tackling real problems with reflection and thoughtful engineering can turn failure into lasting innovation.

If you enjoyed this story, feel free to connect with me through my Linktree 🌳, where you’ll find all my social links.

Thanks for reading.

– Alon