Scalability. More users accessing static content may put your web servers under heavy load. Add more web servers to alleviate the problem. If more business calls are made (users search stuff, access dynamic content a lot etc ) your app servers may need to be better load balanced.
If a fail over is required at all
No fail over required and very limited users mean no need for additional servers. One server will do. As long as the user will not tear out his / her hair for loss of service
If number of servers affect user experience of the system
If you have a ton of users firing search queries with bad criteria, and your search logic is crazy enough to fetch all the results there will be a range of problems.
1. Memory since you will want to cache the results. This means more RAM for app servers or more app servers (if you do some business logic along with the search).
2. Better load balancing for database servers since they are being killed.
Some apps need more memory, some need more database access and some have a lot of static content in them:
I like to cache stuff in web app scopes in most of my apps. I usually make a rough calculation of how much memory I need by serializing all the cached object on a disk. Say I have these files
user.ser - 10 kb data.ser - 190 kb
One user would take somewhere near 200KB of JVM memory (This need not be accurate. It is not necessary that this size and the size in memory are the same.) So calculate the numbers of users you expect in your system (max). Say 200. So you need about 40 MB memory for the cached objects. Set your JVM ram so that you can accommodate this space. You also need to give the JVM some room to breathe.
A data mart is an example of a data intensive app. There are millions of records that are loaded everyday. It can also be memory intensive if there are join operations that involve large amounts of data. This is more a write intensive application. But an example never the less. Tune tables for better write performance. Reports are usually taken from some place else.
An organization may use a lot of static content on its web page. If more people hit these HTML files then increase the number of servers that provide for this static content.
Of course these are very general scenarios. The solutions also may not fit some of the problems described since you need to collect a lot of data before you give a verdict. Here is a real life example
We were migrating a data mart from version X on a normal server to Y on a VMWare server. Version X is hosted on a machine that runs on 4, 1 gig processors. Version Y is migrated to a machine that runs on VMWare. This machine has 1, 3 gig processor dedicated to running the datamart software. The other processors are used for something else. This version Y had performance issues when loading large data. The CPU usage shot up to 100%. Initially we felt that there were not enough processors to support the operations. After adding one more processor the CPU usage seemed a little better but still it was hanging around 90 to 100%. After more careful investigation it was found that the data mart software was not using enough RAM. There was 2 GB of RAM available and the software was using 64 MB. When the join operations kicked in the memory was not enough to finish these operations (these are flat file joins not database joins). Changing one property in the config file sent the CPU usage back to around 30-70% during stressful loads.
Hope that helped. With architecture nothing is ever right or wrong (in most cases anyway). Its all about fixing the problem with the best solution. Good luck with your exam