CODEWITHSUNDEEP
mysqlweb-servicesdeploymentmicroservices
MikeG
MikeG

Reputation: 1275

Microservice Database shared with other services

Something I have searched for but cannot find a straight answer to is this:

For a given service, if there are two instances of that service deployed to two machines, do they share the same persistent store or do they have separate stores with some syncing mechanism (master/slave, clustering)?

E.g. I have a OrderService backed by MySQL. We're getting many orders in so I need to scale this service up, so we deploy a second OrderService. Where does its data come from?

It may sound silly but, to me, every discussion makes it seem like the service and database are a packaged unit that are deployed together. But few discussions mention what happens when you deploy a second service.

Upvotes: 4

Views: 1528

Answers (1)

Bogdan
Bogdan

Reputation: 24590

Posting this as an answer because it's too long for a comment.

Microservices are self contained components and as such are responsible for their own data. If you want the get to the data you have to talk to the service API. This applies mainly to different kinds of services (i.e. you don't share a database among services that offer different kinds of business functionality - that's bad practice because you couple services at the heap through the database and it's then easy to couple more things that would normally be done at the API level but it's more convenient to do them through the database => you risk loosing componentization).

But if you have the same kind of service then there are, as you mentioned, two obvious choices: share a database or have each service contain it's own database.

Now you have to ask yourself which solution do you chose:

  • Are these OrderServices of yours truly capable of working on their own, or do you need to have all the orders in the same database for reporting or access by other applications?
  • determine what is your actual bottleneck. Is it the database? If not then share the database. Is it the services? If not then distribute your data.
  • need to distribute the data? What are your choices, what are your needs? Do you need to be consistent all the time or eventual consistency is good enough? Do you need to have separate databases and synchronize them manually or does your database installation handle replication and partitioning out of the box?
  • etc

What I'm trying to say is that in this kind of situations the answer is: it depends. And something that we tech geeks often forget to do before embarking on such distributed/scalability/architecture journeys is to talk to business. Often business can handle a certain degree of inconsistencies, suboptimal processes or looking up data in more places instead of one (i.e. what you think is important might not necessarily be for business). So talk to them and see what they can tolerate. Might be cheaper to resolve something in an operational way than to invest a lot into trying to build a highly distributable system.

Upvotes: 5

Related Questions