Well that depends. Are you going with micro services because it’s fashionable or because different parts of your backend work with completely different data and don’t need to communicate with eachother that much?
I’m of the opinion that anything that needs to share one database should be one service, and things that are so easily detached that you can just plop the tables over into a separate database, can be separate services, because that will allow you to scale up one without scaling the other and one database’s I/O won’t get in the way of the other database’s I/O (assuming they’re on different machines of course). I’d say:
Well that depends. Are you going with micro services because it’s fashionable or because different parts of your backend work with completely different data and don’t need to communicate with eachother that much?
I’m of the opinion that anything that needs to share one database should be one service, and things that are so easily detached that you can just plop the tables over into a separate database, can be separate services, because that will allow you to scale up one without scaling the other and one database’s I/O won’t get in the way of the other database’s I/O (assuming they’re on different machines of course). I’d say:
Microservices ~ monolith > Distributed monolith
Distributed monoliths suck.