I can't say I've ever put something in my cart, not logged in to Amazon for months, gone back to see it still there, and thought "wow - they must use some sort of webscale storage solution - I'm now going to buy the thing I didn't want to buy six months ago."

From the point of view of solving the actual business problem, therefore, I think something based around Memcache would work just fine!

Dynamo is very useful for persuading you that working for Amazon would be interesting, though.

Here's a 2007 post: http://highscalability.com/blog/2007/9/18/amazon-architectur...

In short (and filling in some of the gaps with my interpretation), they used "one big Oracle database" up until 2001. The webapps originally talked directly to the database (presumably with local caching), but they introduced an application tier later on. I'd imagine this was as much for data integrity reasons.

As they outgrew the one big DB approach, the service approach also let them split their database along service boundaries. So each service still used one big DB, but there were many services.

My understanding is that now there are hundreds of services, and each service is run by a team that can choose their own internal components. But each team is directly responsible for their uptime; if their service breaks the developers get paged in the middle of the night. Traditional databases are therefore still widely chosen; even if sexy technologies like Dynamo get the press.

"Dynamo for show, Oracle for dough" to mutilate an old golfing expression :-)