Running two applications on top of the same database

I have a site that's growing large, and has very separate needs for different users. Until now, one application has sufficed for serving all user needs.

Now that we're growing, I want to separate the code base out so I have an application to serve for each major use case. In this context, when I say application I specifically mean web applications.

My initial thought was to create a master API application that acts as a web service to facilitate all the functionality of each application. However, when I thought about that further, I thought that using HTTP as what is essentially a data layer will really kill performance and I'd rather not throw hardware $ at that problem to fix that.

On the other hand, I hav开发者_JS百科e very robust data models (using an ORM) that I could easily copy over to each application. As long as I made sure that this data model layer remained the same for each application, I think I should be able to expect data consistency across each application.

What else should I be concerned about? The more I think about this approach, the better it seems to me -- Apache already normally spawns an instance of the current application for each client, so several applications are already accessing the database all at once. This architecture should the same, just the code that is calling the database queries would be different.

Are there any other con's I'm missing here?

For the record, the technology stack is standard LAMP.

I think you are on the right track.

Consider any useful and complex website, for example Stack Overflow. It has one interface (application) when searching for answers to a question. It has quite another one when reading answers to a question, and yet another for answering a question. It has yet another application paradigm for moderation. And it has a sophisticated ability to migrate questions to other sites.

And yet they all coexist happily. The data model is key, but so is code which preserves and protects integrity of normalized data.

As for scalability, Wikipedia has a similar model. Scaling is solved by using four (maybe five) database servers, one the master and the others as slaves. Any d/b server can respond to a read query, but only the master accepts writes. Of course there are also hundreds of webservers which run "the applications" and there are also hundreds of web cache servers to balance performance. But the database architecture mirrors the fact that 99+% of all page hits are reads.