"Platitude. Deduct two points. You might also say 'replicate too
little and scalability collapses'".

Poor debating style. And nope, the reverse isn't necessarily true.

"The art is breaking a very large database into manageable size
objects. There's more danger in making them too big than too small.
Another part of the art is keeping request/response round trips to an
absolute minimum. In fact, I'd say there's a lot of art to be done."

Yup, and I thought we were discussing that art. Anyway, any design
that requires more than minimum replication between nodes will smudge
partitions over way too many nodes. Well, that's my view of the art.

"I think more like processor affinity in an SMP scheduler. Send to
process to where the data is likely to be in cache. If it isn't
here, take the hit and get it."

Easily said, but deciding where the data is most likely to be is not
trivial -- especially in when designing in RESTful way.

I hope you have thought it all through to a much more fundamental
level than you give the impression in this thread.

Paul