Well, depends on how you want to approach it.
The first approach I would see is to have tables namespaced by context with no relations cross-contexts schemas. So you would have two different tables for users - one in the services context and another in the account context. The tricky part is to coordinate changes between then, which you could do using transactions - again, passing through all contexts that have the user schema for example if you want to change the user. The other way is to create a small GenServer
module, where you would do a simple PubSub
registration/listening and, everytime one of your users tables are changed it should broadcast a message with relevant information that will be captured by the other PubSub
GenServer
s, so it can be propagated into their own versions of users.
The first approach albeit simple, when you need to scale into microservices your monolith will force you towards the second approach and you’ll have lots of pain because you coupled your cross-contexts relations in the same app. The second approach is more decoupled and, as I stated before, can be moved towards its own service, separated database whatsoever without you caring much of what’s going on.
It’s either a mixture of personal taste and what you’ll need. Do you think you’ll need to scale to millions of users? If yes, then, I would go second approach. If not, well, the first one is cheap and does the job as well.