Twitter is a multicast-capable software-based crossbar switch, with a necessary form of message journaling and replay. Where the destination of or target of th

Twitter is a multicast-capable software-based crossbar switch, with a necessary form of message journaling and replay. Where the destination of or target of the message is what selects and pulls the messages. And with sparse addressing. Twitter reverses the norms of routing; the receivers control the routing. It's a distributed forest of packet-cloning and routing servers. And the entirety of the routing tables involved here are stonking huge. I'd not look to apply nor use Rails and typical databases here (first); I'd approach this from a completely different direction. This application just doesn't fit into a classic database. You're not even sharding the right pieces here, if you're looking at the database(s).