Massively scaling sites by offloading functionality and using MongoDB

High-traffic websites (as in millions of page views per day or week) that still use a single database for writes can choke on high-volume user-submitted content (comments and ratings) and forms (contact, requests for information, job applications). Writing to a single (master) database creates problems not only for scale (holding db connections and I/O), but for replication and backups (large tables take forever to re-initialize a slave, and create backups). It becomes important to be able to write these sorts of things to a secondary database/storage entity. I'll cover how to successfully write to a different database, including how to still use Drupal's database API (hook-schema, db_write_record, etc.) and to cover pitfalls and successes.

Some applications just don't make sense as a Drupal module, in spite of the fact the primary functionality will still take place on a Drupal site and needs to integrate with it. These reasons may be for simple scale (need to store in something like MongoDB) or the cost of a Drupal bootstrap is too expensive (making tiny, but tens of thousands of AJAX/JSON requests). I will cover how to reuse Drupal APIs when it makes sense, and how to write a separate web service that Drupal can talk use without it being a Drupal module.