Designing A Multi-Tenant System With DynamoDB

Imagine an application that stores multiple organizations’ data.

This can be, for example, an e-commerce application that lets multiple sellers sell goods to customers (similarly to Amazon.com).

In this multi-tenant system, the data should be both physically and logically separated, both on the storage servers as well as programmatically on the database.

The separation of data is a common requirement with use cases like e-commerce or cross-organization data management. The motivation behind this is usually that one customer’s data should not mix in or “leak” into another customer’s data.

However, data privacy is not the only reason behind multi-tenant systems. Being able to logically separate data by “tenant” makes it easier to manage the data and perform analytics against it,

How DynamoDB supports multi-tenancy

With DynamoDB, these requirements are pre-built into the database system.

Data on a DynamoDB table is physically stored on separate storage nodes based on its partition key. By selecting the partition key yourself, you also decide how to separate your data logically.

This works well with systems like multi-tenant systems.

Let’s take a look at how we can design a multi-tenant database in DynamoDB. This will let us understand how DynamoDB makes it easy to design for multi-tenancy by default.

Multi-tenancy Data Design

Let’s take as an example, our e-commerce system and see how we would design our necessary data — such as orders and customer records — based on the multi-tenancy requirements.

Here we can make several different design decisions based on scalability and maintainability.

In other words, if we do not have high scalability needs, we can partition each item (orders, customers, products, etc) under a seller’s ID. 

If we have some scalability needs but want to balance maintainability, we can partition items under a combination of the seller ID and a customer ID. 

Finally, if we have high scalability needs, we can partition items under a combination of the seller ID, customer ID, and another sharding value like date or region.

To clarify this, let’s look at a few examples below.

We’ll design data models for the following trade-off scenarios:

• Favoring maintainability, sacrificing some scalability

• Balancing maintainability and scalability

• Favoring scalability, sacrificing some maintainability

The data model representing orders placed by a customer, under a specific seller, can be designed like so (we’ll use “pk” and “sk” as the names for our primary keys):

Data Model 1.a (favoring maintainability)

This is the most common use case for multi-tenancy. 

In this data model every “tenant” (i.e seller) and their data is partitioned seperately from other tenant’s data.

Data Model 1.b (balancing maintainability & scalability)

With this data model, we are anticipating more traffic and try to avoid hot partitions by “sharding” the partition key with a more specific value (i.e. customerID, productID).

This offers us scalability while still being able to have good data model maintainability.

Our data still respects the multi-tenancy requirements.

Data Model 1.c (favoring scalability)

Notice how in this last data model we are getting increasingly more scalable with each item.

The first item shards customers over a given city or region and lets us query for their orders.

The second item shards customers by region and customerID.

The third item shards customers by region, customerID and the suffix orders to separate customer orders from customer shipments or other customer-related data.

Conclusion

The bottom line is this:

Model your data based on your tradeoff between scalability and maintainability.

But whichever approach you take, multi-tenancy can be achieved in DynamoDB with ease and by understanding your application’s needs. 

👋 My name is Uriel Bitton and I hope you learned something in this edition of Excelling With DynamoDB.

📅 If you're looking for help with DynamoDB, let's have a quick chat.

🙌 I hope to see you in next week's edition!