If I were going to do this I would integrate input from user actions as messages using a serialization like Thrift or ProtocolBuffers and likely an AMQP transport. This allows you to hook into the system in a number of places with whatever language makes the most sense. Getting data to the presentation layer is going to be really dependent on what type of data you're dealing with so it's hard to give a pat answer to that, but in the most basic of cases, you can continue to use a messaging based approach and combine it with a distributed hashtable/cache system.
This approach allows you to hide the data models of both parts of the system from one another so you don't end up back in the hell of integrating via the database, which is what I suspect you were driving at with your question. You obviously can't avoid having to share some information between systems, but in this model you can share message and service contracts rather than database schema.
That's smells a bit of architecture astronaut to me if you don't mind me saying. Sharing information between systems is a tradeoff (vs arch complexity), not something to be avoided at all costs.
It certainly is not appropriate in every circumstance, but it can make a lot of sense for larger applications where you might have different people or even teams responsible for different parts of the application.
This approach allows you to hide the data models of both parts of the system from one another so you don't end up back in the hell of integrating via the database, which is what I suspect you were driving at with your question. You obviously can't avoid having to share some information between systems, but in this model you can share message and service contracts rather than database schema.