Microservices: Real Architectural Patterns
Camille Fournier

Thanks for sharing your experiences. It’s nice to hear some stories of microservices in practice.

We’re a small team and have found that microservices work really well for us too. It’s a nice way to completely sidestep the issues you encounter when the whole team is working on the same application. We work in pairs and almost always manage to have each pair working on a separate service.

I completely agree that complex service discovery needn’t be a prerequisite for building microservices. It’s a shame that so many posts and talks give the opposite impression. Each of our services has a DNS entry that resolves to a load balancer and that’s all we need.

We moved from a single shared database to a database-per-service after about 6 months in production. The worst thing about the shared database was the nagging fear that we would break one of our conventions and accidentally delete data that was being used by another service. Moving to separate private databases and mandating that all communication between services happen via REST or a queue made that fear dissolve completely.

In retrospect, the important part here was that we stopped using the shared database to pass data between services. However, just as it’s harder to create clear boundaries between domains when the code is colocated, it’s much harder to get the data part right when everything’s in the same database.

The move to a separate database for each service also paid off when our querying requirements became more complex. We were able to switch some of our services from Redis to Postgres with minimal fuss. This would have been impossible when we were using a single Redis database for all of our services.

A lot of microservices writing advocates the separation of databases first. Based on our experiences I don’t think that’s bad advice, but I disagree that it’s a hard requirement for teams that want to start building microservices.