Louis Gabriel wrote:
What I'm wondering is what kind of architecture would one have to have in place to handle 12,000 db backed request per second (say, for example with a three table query for each request processed).
What I'm wondering is how you came up with this number? Sites whose load peaks at 12,000 DB-backed requests per second would have to have tens of millions of users. A few things you said lead me to believe that you don't really anticipate that kind of load. For instance, you said,
Lets say, for instance, that you have a web service used by 12,000 external users
To clarify, it won't be 12,000 request per second **every second**. But it will be 12,000 request per second several times throughout the day. 12,000 db backed request per second is a peak load number, not an average load number
The users will have different points of access probably about 20,000 at least -- from all over the United States -- but not the world.
It sounds like you are going to have 12,000 users total -- not millions of users handling "large amounts of money." In that case, there is no way in hell your site is ever going to receive 12,000 concurrent requests per second. It's like saying that if Verizon has 10,000,000 subscribers in New York City, it must have the capacity to handle 10,000,000 concurrent phone calls. Guess what. Verizon doesn't have that capacity.
If your estimate of 12,000 db-backed requests per second is based on the historic data from an existing installation, that's one thing. Otherwise you'd have to know about things like queueing theory, M/M/K/K models, and crap like that to be able to estimate the likelihood of getting more than n db-backed requests per second.
In other words, please clarify where the number comes from.