Databases Make Bad Routers …

by bob on May 1, 2008 · 3 comments

in Editorial

rails.pngTechCrunch is reporting that the new guys at Twitter have already decided to drop Ruby on Rails.

The comment thread on that post has been almost comical. Some folks are wondering if this is a political decision, some think the DB isn’t optimized, some people think it’s Ruby’s fault, some people are appealing to Twitter to not abandon the RoR community.

This is just nuts, & everybody should just calm down.

The Simple Truth
The application in question (Twitter) is fundamentally a messaging problem, & a modest one at that. Putting a DB into the flow IS THE PROBLEM.

Twitter has been asking a DB to act like a router, something which it is pretty bad at doing.

Why be surprised when it doesn’t work?

.

{ 3 comments }

Helga May 2, 2008 at 7:48 am

Hi,

I was actually going to write a rather overbearing comment on this entry, but then I read another one of your entries http://www.appistry.com/blogs/bob/biz/how-make-twitter-scalable which I totally (well mostly) agree with.

I don’t think the problem is the database as such, but if you are relying on a framework which doesn’t really have any business layer, you are kind of screwed. So I think that Twitters problem is rather the lack of a business layer, resulting in db overuse, rather than having routing decisions in the db. That can be a good way to go, as long as there is some intelligent handling of the routing itself, as you describe in your previous entry.

Louie May 2, 2008 at 3:59 pm

You kind of have to put an RDBMS into the mix because RoR, as a soup to nuts implementation, is tightly coupled to it for persistence. If Twitter chooses to keep RoR it will have to moderate the I/O its DBs see (caching, more iron) or move to a cloud based DB (SimpleDB, BigTable, etc.). In either case the solution will be messy. I agree that Twitter is more a messaging protocol than an MVC application. Such apps would benefit more from a tool like say Erlang than a web-based CRUD framework.

Anonymous May 3, 2008 at 4:41 pm

Helga, just curious — how do you define “business layer?” How would you distinguish this between a proper domain model, that cleanly separates business logic? What frameworks do you think have a proper business layer? And please elaborate how the business layer would insulate the db from overuse.

Comments on this entry are closed.

Previous post: Working Out Problems With Comments …

Next post: The Spring Application Platform