There are scenarios when a single instance model is bound to fail. The peak load scenario. Let’s say there is a coporate deadline for filling out appraisals. As most people do this as a least interested task, the last day or the day before is when the load on the system is going to be high. And being a single instance it is (no doubt there will be multiple app servers, load balancing and all the good stuff, and perhaps even a RAC configuration on the database side, but still a single database), the apps start crawling instead of running. And it gets annoying, while on one hand, people would like to meet their deadline, and on the other, the system doesn’t cooperate. This further aggrevates the problem as people often try to login and logout, close the app that’s crashed in the middle and restart and so on.

Same may be applicable for apps deployed for a university. There will be peak load for course registration, peak load to pay the fee etc.

In general, there are 2 types of partitioning choices for apps.

1. Partitioning by functionality (purchasing vs invoicing)
2. Partitioning by geography (US vs Europe)

While the first 1 will usually end up as an integration nightmare, with a well planned execution and a decent data warehouse, the second option is not bad afterall.

There may also be a lot of non-relational data that can be optimally served to everyone within the organization using edge computing (http://www.edgecomputing.org/uc/lucene.html) than putting everything in one single database.