A database for your microservice (part 1/2)

Why should you, a microservices developer or architect, care about databases? That is the first question Quinten would really like to answer.

As you know, the microservices way of working is all about the independence of services. It seems quite logical that each one of them should be responsible for its own persistence layer. This gives you the absolute freedom to choose something that fits the needs of your little service perfectly. That’s awesome! Right? Well yes, however… Choosing a database is not easy. There are a lot of possibilities out there and making a choice has some very real consequences. Luckily, a microservices approach is much more forgiving for making mistakes, but making the wrong one can still come back to haunt you in production.

As a small disclaimer, I should mention that I am by no means a database expert in even one technology, let alone in all of them. However, by having a good high-level understanding on what’s happening under the hood, I could at least eliminate some of the risks that come with choosing a database. I hope to do the same for you

Before you start, there are some of the questions that need to be answered:

Do you need your database to be distributed?
Is your data relational?
Should you consider NoSQL?
What’s ACID and the CAP theorem and where do the requirements of my data fit in all that?
What skills do your team have and what kind of investments are you prepared to make?
Should you host it yourself or should you consider a database-as-a-service completely managed by a cloud provider?

To keep things focused, we’ll leave the last two questions up to you. As to ACID and CAP Theorem. There are many, many, many blogs and articles out there, that’ll tell you what you need to know.

The most important question should always be about your data being relational or not. Before you even start to look at the plethora of NoSQL database offerings that seems to grow by the day, take a minute to think about the nature of your data. From my experience, most of the data we come across is relational and structured. If it is, there are not many reasons to consider NoSQL.

Other arguments often brought to the table are scaling and performance. Admittedly, doing this yourself is probably easier with most NoSQL databases, but remember that you can always offload that problem to your cloud provider. Solutions like Amazon RDS and Azure SQL might seem expensive, but the cost of setting up and managing your own on-premise proprietary solutions are often highly underestimated.