Wow! That was fast. Rails community really has it together. Thanks for sharing this!

I heart the Rails community. Not only did Nic cure the database concurrency problems exposed in Rails by Twitter – he did it without being asked, he shared it with everyone (as a Rails plugin), and he did it in 75 lines of Ruby.

Word.

Database cluster sounds about right. Although if you have a single master node ruining the actual database server, you still get in trouble. What you would ideally want is to have several nodes listening for connections.

But then you run into concurrency hell…

i’m not a fan of rails — but a database cluster is the correct solution here. the way to have rails talk to multiple database is to have multiple rails apps. with gems, the code sharing works cleanly.

not sure how you’d “split” things otherwise at the model level. you can partition and play caching tricks, but that’s just delaying the inevitable.

due to concurrency issues only the database knows what needs to be updated and when. alex’s quote referencing “read-only slave databases” and “caching” indicates that he hasn’t really thought about the problem and is just another guy wrestling to make a half-complete system, complete.

Cal from Flickr wrote an O’Reilly book that outlines some of the problems, even if the solutions are a little “on the sly” by enterprise standards. still, it’s tough to argue with the results. though note that he talks at length about the amount of extra code they write that checks and double checks integrity of cache. and they’ve had some pretty bad caching bugs — porn pics showing up, etc.

a lot of this style of systems design is “okay for dopey web site” but not so good for financial or information systems design. whether or not this stuff works long term and ever scales up to “real” reliability remains to be seen.