Last time we started talking about how websites such as Digg are dealing with scale by deconstructing the database layer ... that is, in order to deal with scale they are asking less and less of their database.

So far Digg is getting away with that because as they say

Ellis acknowledges that Digg.com "is really lucky" in that 98% of the time the database is accessed, it is being read, as opposed to experiencing more intensive data writes. "Most people come to Digg’s front page, read it and leave, which is kind of nice," said Ellis, drawing a knowing laugh from the audience of mostly PHP developers and DBAs.

In other words, so far their users are satisfied with a few simple pages, a few clicks, then away they go. I think the key phrase here is "so far...". Keep reading that article and you'll see this curious quote

Preventing Digg’s enthusiastic developers from adding powerful but CPU-intensive features is "a political thing I constantly have to deal with as a DBA," said Ellis.

Let's think about this from another perspective for a minute. Digg needs to more or less continuously add functionality to the site. The needs of the business demand it. To quote my favorite replicant-hunter (Harrison Ford as Lt. Deckard in Blade Runner) and Bryant (his erstwhile boss) confronting the need to hunt down wayward replicants ...

"No choice, huh?" ... "No choice pal!"

This isn't a political battle, it's a fight for the future of that business ... and they'll either figure out how to add those "powerful but CPU-intensive features" or a competitor will ... maybe someone using a fabric!

One of the really great possibilities opened up by application fabrics is the very possibility of adding "CPU-intensive features" wherever you'd like ... perfect for constructing a sort of Digg 2.0 (and beyond).

Technorati Tags: data grid, scale, scale data, scaling db, scaling Web 2.0, shards, web 2.0