Just read this article: https://microservices.io/patterns/data/database-per-service.html We are designing 2 microservices - both have tables in a shared db. What I'm wondering is if I build an API that provides access to these sets of tables... where should this (HTTP REST) API be installed? on a separate application server? or right on the database server itself? I'm leaning towards a separate APP server so that I can spin up as many app servers as I may need in future; and that the only place state is maintained is on the database server itself... but just want to be 100% sure.

  • 3
    There's no "100% sure" here. Evaluate the likelihood of requiring multiple servers in the future, and decide if the work saved today by using your existing server is worth the work it might take to move it to a new server later. Then, make a decision. If you design the thing correctly you ought to be able to move it wherever you want, whenever you want. Isn't that kinda the whole point of going to the trouble of having a microservice architecture anyway? – Robert Harvey Nov 6 '18 at 17:06
  • 1
    Why not make your server "generic" so that it doesn't matter? Run it on the database server for now, move it when it needs moving. Should not be too hard right? – fstam Nov 6 '18 at 17:10
  • Thanks guys. Good comments. Yeah, i think the big win for phase 1 will be the fact that we have an API into the db and we no longer tap into the db directly. and if we design it right, then yeah, we should be able to defer the decision to split off the API until later, when / if we really need it. – dot Nov 6 '18 at 18:07
  • Are you aware of that implementing a CRUD service to access DB will, literally, remove ACID transactions everywhere? On the other hand, don't you think that it worth the cost, to dup code in each service instead of paying the overhead of deploying a service that will probably "bound'em all into the darkenss" and its likely to change quite often? In other words. What's the value (for the company) of such service? – Laiv Nov 7 '18 at 14:50

The microservices provide an API to their data. The services themselves can access their own data directly, there is no need to add an extra abstraction in between. In this sense, the database is an implementation detail of a microservice.

If you want to expose a different API than your microservices offer, that would be a separate service or a kind of API gateway, but this API shouldn't know about the databases directly.

In any case, only build what you need. You can refactor the internal structure later if it has proven itself unsuitable. For example, if you deploy your microservices on-premises for clients, you may want to interface with whatever database system that client already uses. Then, some kind of persistence service to abstract over any differences could make sense.

Note that “server” can mean both “a piece of software that responds to requests” or “a piece of hardware that sits in a rack”. Every microservice should be their own software-server, though they may share hardware. However, larger databases have unique hardware requirements, in which case you should not run other services on your database hardware. In a cloud setting, all of this would be abstracted away anyways, especially when using some container orchestration mechanism.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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