Right out of the gate we need to understand
there is a price for loose coupling: complexity. Loosely coupled distributed systems are harder to develop, maintain, and debug.
(more)
That being said loose coupling is an important aspect in designing for replace-bility.
Is the data for these applications actually stored in distinct databases? If it isn’t, you may already be in trouble from the autonomy perspective. If it is all stored in the same database it may make sense to create a separate set of queries for each application - if you have a look at diagram in the Bounded Context article you will notice that both the Sales and Support context have their own, separate Customer representation tailored to the specific needs of that context rather some singular canonical representation - because sharing of all-in-one representations can lead to coupling to irrelevant details.
Even it you decide to go the GenServer route you may want to think about Consumer Driven Contracts - i.e. have the GenServer(s) under the control of the Customer application but deploy a separate GenServer for each distinct Customer representation.
Another tactic is Command Query Responsibility Separation. I.e. if modifications to customers is permitted from outside of the Customer application the simplest implementation could offer separate GenServers for query messages and for update messages - simply to get the benefit of keeping these concerns separate.
Now I’m not saying that any of the above applies to your particular case, likely most if not all would be considered over-engineering. But it’s probably worth your time to explore these options and document why any particular option was dismissed (in many cases it is just as important to know what was considered in the past and why particular avenues were not pursued).
