The point of a microservice is you can build it on anything, and change what you built it on over time, without changing its interface. As for your concerns...

The point of a microservice is you can build it on anything, and change what you built it on over time, without changing its interface. As for your concerns... you know how every time some good idea pops up people have to ruin it by pushing it to ridiculous extremes? Case in point, microservices. You don't have to make things so modular that you give up SQL, transactions, or anything. With experience you'll naturally start finding where the domain of each microservice falls, and coordinating between them won't be a problem. I strongly disagree with the poster who said that having joins means it's not a microservice anymore. That's non-sense. A microservice is defined by what it does, not how it does it. Even the simplest service might be managing several entities that are in some kind of relationship. If the entities in one service are not in strong relationship with one another, it's a sign you can split them in two services. But if two microservices talk to each other so extensively, that the service boundary is becoming a bottleneck, it's a sign that they should be one service. Do not break down a service into several services, just because it manages 2-3 entities. That's counterproductive, and it'll be the topic of DHH's upcoming blogpost "Why microservices suck" sometime in 2017.