Preamble: I'm not being negative! I always appreciate any effort to elucidate complicating matters--especially those on matters I happen to have a vested interest in--but seeing as this is A Really Challenging Engineering Problem That Lot's Of People Like Myself Spend The Better Part Of Our Careers Trying To Solve and it's being offered up in a pithy, bite-size, 1000-word blog post on "Designing Web Applications for Scalability", well, I'm going to have to get out my red pen.

The entire subsection on "Choosing your data storage setup" is completely inconsistent precisely because it attempts to tackle such a huge problem in the space of a few paragraphs. Couch and Redis don't even partition out of the box, Tokyo Cabinet only does so with the help of Lightcloud, Mongo's auto-sharding is still unready for production, and Cassandra and Voldemort are fully distributed clusters for whom replication and partitioning mean very different things (and, incidentally, using "partitioning" and "sharding" interchangeably is one thing; doing the same for "shard" and "node" is very different).

And of course by muddying the waters with respect to the datastores themselves the entire treatment of designing a schema is similarly inconsistent. How can you have a universal keying strategy when you don't even know the terms of your discussion? Are you hashing to shards or to a ring? On the client side? With Zookeeper? Or with a messaging service?

Anyway, I wholeheartedly agree with the author's spirit of building for customer acquisition while also building for scalability, but I guess my advice would be "do plenty of homework and never expect to learn everything you'll need to know after reading a hundred blog posts--much less after reading just one."