Multiple physical layers should provide more security, and the ability to have multiple physical mirrors can give reliability guarantees that you can't get with a simpler system.

However I would bet that getting this to work costs huge overhead in terms of equipment and skillsets just to make it happen. I would also bet that the performance (both latency and throughput) won't come near what the same investment could do with a simpler architecture.

Data point. eToys in 2000 managed to serve over 2 million pages per hour in a heavily database-driven site using just a few dozen commodity Intel machines for webservers. (I don't know what the database was.) With today's hardware they would probably need only a handful. Perrin was instrumental in redeveloping the site to hit that load(1), and detailed notes on how he did it are [link|http://www.perl.com/pub/a/2001/10/17/etoys.html|here].

However an explicit design tradeoff was that overall site uptime and responsiveness is more important than perfect transactional semantics. If the webserver that you are being served from goes down, your current shopping basket gets lost. (If, however, you had made a purchase, you can bet that that purchase was securely recorded...) This means that you can cache certain kinds of data on the local webserver, removing pressure on the database and massively improving your potential scalability.

By the time you have purchased a few beefy machines in a failover configuration, and purchased a QA environment, I simply don't see how you could be near their same cost point. And the performance that eToys had in 2000 is still more than sufficient for the vast majority of companies today. Including plenty that swear that they must have many physical layers to get the performance that they need.

Cheers,
Ben

1. A note for Karsten, Perrin ripped out the code that your former employer started with as a load of shite.

Perrin. Not Pippin.

You could always email him at perrin@elem.com and ask. Or I could ask when I see him next. (I think that he is coming out in a month or so.)

But as for Oracle vs MySQL, some better people to ask are [link|/forums/render/user?username=broomberg|broomberg], [link|/forums/render/user?username=slugbug|slugbug] and the like. Perrin was mainly concerned with the website/programming side. He isn't a DBA, nor does he pretend to be one, so he probably doesn't have strong opinions on that.

Cheers,
Ben