Software Engineering Radio - Ebay Architecture Principles

Recently I have discovered a site with fabulous podcasts dedicated to various questions in software engineering, Software Engineering Radio (http://se-radio.net/)

There was an episode on Ebay architecture principles, some of the items from which I decided to rewrite here.

• Partition everything. "If you can't split it - you can't scale it"
  
  
• Functional segmentation. The selling system is distinct from the bidding system and from the buying system. Each system is supported by separate DBs.


• Horizontal splitting. Each functional segment is chopped into smaller pieces. (e.g. if key ends in 1 - the first database is employed, if key ends in 2 - the second database is used, and so on.) On Ebay it is done in a way similar to Hibernate Shards.
  
  
• No distributed transactions are used.
  The Details table is updated before the Master table, if the first fails, the second won't be updated; if the second fails, the asynchronous event will later recover the database from the inconsistent state.
  
  If the Item DB and the User DB should be updated, the importance of having the first one in consistent state is more urgent, so only the Item DB is updated and then asynchronous event is generated to update the User DB later.
  


• No session state is stored on the server. For multi-pages functionality the following approaches are used: URL rewriting, cookies (all the state information is put in the cookie), writing current session data to the scratch database (for multi-pages flows)


• Application features can be switched on and off without code changes
  The code deployment is different from feature deployment.
  Features can be checked for the availability by the code.
  

The whole podcast is available at this link

---

http://www.linkedin.com/in/oldbam