1

I am just looking into microservices and containerization for learning. I have not really implemented anything yet. In principal I get a lot of the layers of the pattern.

One thing I am not understanding and cannot find a good answer on is a microservice's database. When speaking of a database per service is that per each container or is it one database that all services of that app would use?

I have to think it would be the latter but that seems to go against the idea of being self-contained having everything that is needed to run in the application.

Improve this question

1 Answer 1

Reset to default
2

You’re mixing two different types of architecture, and it’s difficult to extrapolate patterns for one into the other. Microservices are part of Network Architecture, which has accepted patterns for how servers should communicate, how to scale apps, and improve resilience for the collection of address spaces that make up your application (think of an address space as a single deployable piece, whether that lives in Docker, a VM, or a physical machine). In this space, there are no recommendations for whether you should have one or multiple databases because it can’t know enough about the business logic to make a recommendation. It does say that IF you need multiple databases per address space, you can deploy them via Docker.

Application architecture has patterns for how to structure the code to implement a single deployable unit. This is where you decide if each installation can function properly with a dedicated database, or if multiple installations of the same code need to share a database. By design, the Application Architecture shouldn’t be concerned whether its running in a microservice. It should know whether it’s sharing a database with other copies of itself, but whether you are using Docker or a VM or a physical server is unimportant.

So break your question shouldn't be about which approach Microservices recommends, it's about which your specific application requires. Ask yourself this question: if two copies of your code are running simultaneously, do they need to share a database to maintain data integrity? If not, use multiple DBs in different containers, where each id dedicated to that code deployment. If so, use one DB in a container that is available to all.

In practice, you will often end up with both a DB for each deployment where cache info is kept (this helps with scaling), and a shared DB for business data persistence (which helps with data integrity). Add CQRS to your list of things to investigate while digging into Microservices. It's an excellent, scalable pattern that works well with Microservices.

Improve this answer
3
  • Good outline. I would not have thought that the cache would be a local db instance but rather events. I guess persisting event to the message bus and a local db might be useful. I am gathering based on further reading and lectures as you said it comes down to what my app is doing. CQRS is on a notepad somewhere to look up.
    – nerdlyist
    Commented Oct 30, 2018 at 13:42
  • The cache is for data that is needed for reference but managed by other apps (or Domains if you're into DDD). It's not for events or messages (these are different, see here bradirby.com/difference-between-events-and-messages for more info). Messages are not typically kept, and events are stored in a central area for all to consume (see Kafka, Kinesis, or Azure Event Hub). In CQRS, the "cache db" is used for the query models that are updated in response to the events. I know this is all a jumble here, but it becomes clear when you get into CQRS.
    – Brad Irby
    Commented Oct 30, 2018 at 13:58
  • Alright time for some CQRS study. Thanks for your time!
    – nerdlyist
    Commented Oct 30, 2018 at 14:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.