Search code examples
dockerarchitecturemicroservices

multiple micro services sharing same database SERVER (One container, multiple dabases)


Is it good practice to have multiple services connect to the same database server but each having their own database. I guess having one Postgres instance is better than each service/container having their own instance.

My question is that should each service:

  1. run in their own container with db server instance in the same container
  2. run in their own container and the db for that service run on a separate container just for the db (multiple db containers/one per service)
  3. one db SERVER, multiple databases, one container for all databases and all services connect this container/db server

I understand that each service should have their own db, but does that also means they should be completely decoupled even server wise.

I guess the reason I want to have one db SERVER is so that resources are not "wasted" as multiple instance of db server running

I also understand that having one server will mean that all services will coupled hardware wise


Solution

  • It doesn’t really matter. Modern infrastructures tend not to care about the overhead of running multiple copies of the same service. Since database I/O can often be a critical performance point, you might find it more manageable to not share a database, so that you can put databases under heavier load on dedicated and/or larger hardware.

    (Also consider running your database(s) on dedicated hardware, not under Docker: they’re the one thing you must back up, and you’ll update them much less often than the rest of your application stack, so their lifecycle is fundamentally different from a disposable Docker container. If you’re using a public cloud service that offers a managed database service and are willing to pay for it, that can also be a very reasonable option.)

    Whatever you decide, you almost definitely need to make all of the parameters (host, database, username, password) configurable, usually via environment variables. (I see too many SO questions that have host names hard-coded in source code.) You should be able to deploy the same image with different options in development, test, and production environments, which will generally have different host names.