I’ve run into a dire situation where I can’t make up my mind on the best way to proceed. Plz help.
I have a three apps.
Used by regular users like Jane and Joe. Registered users only.
Used by business users like Microsoft and Apple. Registered users only.
Public facing app that lists the businesses in app 3, browsed by users of app 1 and anonymous users.
App 1 has a huge amount of data created by Janes and Joes. App 2 has an equal amount of completely non-related data created by Apple and Microsoft. App 3 calls both app 1 and app 2 to get data from both as needed.
The only overlaps in data (as we know today) are these cases:
- Jane and Joe can send messages to Apple and Microsoft, and vice versa
- Jane and Joe can mark Apple and Microsoft as favorited companies
- Jane and Joe can browse businesses either in app 1 or app 3.
Option 1 - Hosting everything in one database
- One less database to maintain
- Easy to point both apps to the same database
- Lots of non-related data in one DB
- Less resilient, one DB hiccup takes both apps down
- Less distributed, more load on that one DB
- Have to maintain a distinction in the user documents, is the role
- Complex user document schema
- Complexity in logins etc. to make sure users login in correct places
- Risking that updating one app requires updating both apps
Option 2 - Two separate databases
- Clear separation of the two domains
- Resilient, one DB hiccup or attack doesn’t necessarily take both apps down
- Distributed load between the two apps
- No need to worry about mixing the (completely different) user document types
- More work and money required to host two databases
- More work needed to get the two apps to communicate securely
- Expected weird edge cases, eg. what happens when there is a potential
_idclash among users of different apps?
Since I’m maybe forgetting some important aspects, I thought I’d ask here for input. There’s even a poll! Any feedback highly appreciated
- One database
- Two databases