Tuesday, November 27, 2007

How eBay Scales Up

Here are a couple of presentations giving an overview of eBay's architectural approach and reviewing how the architecture has evolved.

Of note:
  • No session state in application tier (use URL/cookie/scratch DB)

  • No business logic in DB & no stored procedures

  • Partition everything - if you can't split it, you can't scale it

  • Async everywhere via message bus & periodic batch processes

  • Everything fails sometime, so all operations must be fault-tolerant

I manage an ecommerce site that has a single centralized DB (I inherited this architecture when I took it over). That single unpartionable DB is a HUGE headache, and eBay's architecture has me thinking... can I get rid of the DB altogether except as a reporting mechanism?

We know we need to be able to split the DB across multiple geographic sites soon. But this DB stores user account information and orders - so, why use a DB at all? Why not store user account info and order info in XML files in the file system, index them with Lucene for searching, and use async messaging to report order info to other systems that need to know (fulfillment, reporting)? I'm simplifying, of course, but in broad strokes this should work and scale very nicely.

No comments: