Can the DynamoDB "single table design" play nicely with a Microservices architecture?

Question

Microservices - multiple DBs/tables

When I first read about Microservices (MS) one of the most striking things was that each MS has it's own DB. I think I understand this concept now and I am embracing it.

NoSQL DBs - single table

I then started researching NoSQL DBs, namely DynamoDB. I watched this deep dive video where the presenter discusses the idea of taking a relational model - say 4 tables, and representing the data in one table. He then uses various techniques to make the data super fast to query even at scale.

Again, I think I understand this concept.

Combining the two is where I get confused. MSs want me to split things out into separate services and therefore separate DBs (or tables) but NoSQL patterns want me to have one table....

Do these 2 design patterns/architectures not work together or am I missing something?

Answer 1

If you combine the two ideas, then you end up with each microservice having its own database, and each database having only one table.

If you have multiple micro services running in the same AWS account, I can see why you might be confused because you would end up having multiple tables in dynamodb. There are some questions I will address to try to clear things up for you.

How can I have separate databases in DynamoDB?

In DynamoDB, the notion of “separate databases” isn’t a very meaningful idea. From DynamoDB’s perspective, each table is independent of every other table (unlike a relational database). There’s no hardware you need to manage, so you can’t see whether your tables are on the same servers or not, and there’s definitely no concept of database instances.

How can I have separate databases if DynamoDB doesn’t have “separate databases”?

The goal is not necessarily to have a separate database for each micro service. The goal is to make sure that the only coupling between micro services happens through APIs provided by the micro services. Having separate databases is one way to help enforce that (so that the micro services aren’t tied to a shared internal data mode), but it’s not the only way.

So what should I do?

Each microservice should have whatever table(s) are necessary in order for it to function. Any given table should be read and written to by only one microservice. In order to achieve the isolation between micro services which are running in the same AWS account, you should use IAM policies to make sure that each microservice accesses only its own dynamodb table. In some cases, you might be better off putting each microservice into its own AWS account to provide an even high level of separation between them. (An added benefit of this approach is that if one of the accounts ever gets compromised, the attacker has access to only one of the microservices.)