Search code examples
database-designmultiple-instances

app with multiple versions: one or more instances

I wonder what is the best design for an app sold to multiple clients (there is very few differences between each client app: some css, auth method).

I think multiple instances (front + back + db) of our app, one for each client is a better design but I cannot find online sources.

Advantages of multiple instances:

  • robust +++: deployement seems to be easier, we can go step by step
  • agile +++: easy to deploy for specific client
  • gdpr compliant ++: db are splitted by client, no chances to mess with client data (you'll find below a quote from the gdpr guideline)

Drawbacks:

  • need to redeploy for all client after a new version is published

Am I missing something ?

gdpr guidelines:

Effectiveness is at the heart of the concept of data protection by design. The requirement to implement the principles in an effective manner means that controllers must be able to demonstrate that they have implemented dedicated measures to protect these principles, and that they have integrated specific safeguards that are necessary to secure the rights and freedoms of data subjects. It istherefore not enough to implement generic measures solely to document DPbDD-compliance; each implemented measure must have an actual effect. This observation has two consequences.

Solution

  • I think this question would mostly attract opinionated answers and without deep understanding of your case it's pretty hard to claim any of it be applicable. I however wanted to add more points to consider as drawbacks of your chosen approach:

    1. maintaining multiple DBs has more overheads compared to one multi-tenanted DB (think RAM, disk, CPU, separate caches etc)
    2. deployment process gets more complicated - it requires to do multiple deployments of the same package to fix bugs/add common functionality
    3. the above would probably get particularly painful if you found a critical bug that you need to patch for everyone ASAP
    4. assuming some clients are going to use the application more often than others it gets harder to predict and balance the load across your app and DB servers (you either overprovision all or risk missing a user spike on one that's particularly hot)

    There are more good points expressed on this software engineering SE thread.