I would suggest building your site by either loading one WordPress environment and using the WordPress REST API to communicate with the other, or creating your application completely separate of a WordPress environment and using the REST API to communicate with both (heavily dependent on your specific needs and application. If each request makes heavy use of one installation’s functionality, I would imagine it makes more sense to load that installation as the environment to minimize the number of remote HTTP requests incurred).
While the Plugin AJAX approach suggested in the comments could theoretically work it would be something of a hack – AJAX is much more suited to custom interactions between a single front-end and one or more back-ends, and requires that you implement what could end up being a very extensive AJAX back-end yourself (including security mechanisms to prevent potentially malicious unauthorized use and abuse of your functionality).
Meanwhile the REST API is considerably more flexible and inherently suited to remotely accessing core functionality. Custom end-points are arguably easier to implement, and as a result of a different loading procedure REST API requests tend to be about 15% faster than their plugin-AJAX counterparts (both are still much slower than native operations in a loaded environment as both must load some portion of WordPress from scratch for each and every request).
All of that said, I’m not entirely sure why one might need such a division of responsibility between two WordPress installations for a single site – if a performance optimization, I would argue it may be premature and could well end up impairing performance instead of improving it.