I'm trying to get my head around the thought process when designing a large scale application.
Let's say I have a client who needs a new customer website and he is estimating 40,000 orders per day with an already 25,000 user base. When desiging the application, how do you about determining if a distributed architecutre is needed? Should I use a web farm? etc.
I've mostly build 2 tier (physical) applications in the past and I really want to improve my understanding.
Any insight would be great!
Load Test your new application from the get-go.
Since doing a big-design up-front will never give you the results that you expect from it (15+ years of experience) the best thing to do is to design for change and let the right architecture emerge from your requirements.
Given your description, adopt an agile methodology for this project, and use its practices to guide your project into a success. One of those vital practices is to have a 'Definition of Done' for all the work that you do. Clearly in your DoD you will have the item:
As you would then start development, one of the first things to do is ofcourse to set up the environment to be able to run such a load test. If that never happens, you already know very early in the project that you will be in trouble. Having the load test done as many times as needed (at least once every sprint) you will know that the scale requirement is/can be handled by your architecture.
HtH
It's going to depend on a lot of other factors than just the number of orders per day. Where will it be hosted? What does that physical architecture look like? What else does the application do besides ecommerce? Does it need to integrate with other applications (besides the payment gateways of course)? Etc.
A simple two tier application in the right cloud hosting environment (say VMware for instance) that can scale dynamically would work just fine for an ecommerce website. A simple two tier application in the right on-premises hosting environment (load balanced web farm) should also work fine for an ecommerce website. It's the difference between scaling up (potentially hidden with virtualization, which ends up being a scale out of sorts) and scaling out (adding more servers).
A distributed architecture would allow you to distribute the system load (say order processing) to 1:M servers that sit (perhaps) behind a load balancer. This is a very common approach, and would also work very well for an ecommerce website.
In my opinion, there isn't one architecture or system design that fits every mold. The closest architecture to fit every mold (again, my opinion) would be a service oriented architecture. If all business processes and logic are services (and designed correctly), then no matter how your requirements change, no matter what your hosting environment looks like or changes to, and no matter what integration requirements you have, your system can handle it with little or no changes.
Since you are coding .Net, put the application in Azure (da cLOUD man, DA CLOUD! ;).
It will help you get the processing power that you'll need. The application will work fin as long as you do not do any stupid mistakes.
Scaling can be addressed, at least partially, with load balancing.
Concurrency might be your true problem. Distributed transactions is a heavy handed tool, but it won't solve every use case without additional thought.
Some financial companies have additional security requirements regarding the web servers having direct access to the database.
