One reason that customers choose Amazon DynamoDB is because it provides single-digit millisecond performance on any scale. However, this performance depends on an effective data model that supports the application’s access patterns and concurrency requirements. Multi-tenant applications (such as Software-as-a-Service or SaaS applications) introduce additional complexity with unique considerations around performance, scalability, and isolation.
In this series of posts, we walk through the process of creating a DynamoDB data model using an example multi-tenant application, a customer issue tracking service. The goal of this series is to explore areas that are important for decision-making and provide insights into the influences to help you plan your data model for a multi-tenant application.
In this post, we define the access patterns and decide on the table design. In Part 2, we select a partition key design and create the data schema by iterating across the access patterns. Finally, in Part 3, we validate the data model and explore how to extend the model as new access patterns emerge.
Considerations when designing a data model for multi-tenancy
The primary goal when designing a data model is to make queries as efficient as possible whilst maintaining tenant isolation. An efficient data model optimizes cost, reduces waste, and ensures queries are performant. This helps your application scale as your tenants grow without causing significant costs or performance issues.
The data partitioning and tenant isolation approaches you use, heavily influence your data model design. Depending on the deployment model you use, how you partition data and implement tenant isolation may differ. A silo model may not need a specific data partitioning approach, because the table belongs to the tenant. Similarly, you can implement tenant isolation at the table resource level using AWS Identity and Access Management (IAM).
The pool model introduces more complexity because multiple tenants share the same DynamoDB table. You can partition data using a unique tenant identifier (tenantId) in the table’s partition key to associate the item with the tenant it belongs to. However, this introduces the constraint that your data model must include tenantId in all partition keys, which may exclude potential data patterns.
This constraint has greater weight because you can also use tenantId as a data point to enforce tenant isolation. For example, you can implement fine-grained access control with IAM and attribute-based access control, using the dynamodb:LeadingKeys condition key to restrict permissions to only the items whose partition key matches the tenant’s identifier as passed in a session tag.
Another consideration is whether you need to support multiple deployment models. It’s common to have silo and pool models within a multi-tenant solution. Besides different access patterns and tenant isolation mechanisms, supporting mechanisms (such as backup, metrics, metering, and tenant portability) may vary by model, increasing operational complexity.
When using multiple partitioning strategies, it’s important to maintain a consistent data model. For example, when deploying silo tenants, you may use tenantId in the prefix to align with your pool model, even if this isn’t strictly required for isolation. A consistent data model across service tiers simplifies the application architecture, offers standardized data migration within and across tiers, and increases operational efficiencies by enabling single processes for operational activities like metrics gathering, scaling, and cost allocation.
Regardless of the partitioning model, you need to implement operational monitoring to help maintain a consistent tenant experience as your application scales. For more details, see Monitoring Amazon DynamoDB for operational awareness.
For this application, we have selected a pool deployment model. This means there is a single table for all tenant data and we implement isolation using IAM policies. This is important because to implement this, all the partition keys for the base table and global secondary indexes (GSIs) require tenantId as a prefix to use the LeadingKeys condition key. This is shown in Part 2.
For multi-tenant applications, on-demand capacity mode is recommended as the default approach. This mode automatically handles varying workloads across multiple tenants without requiring capacity planning, and ensures that one tenant’s activity doesn’t impact others. Provisioned capacity mode should be considered as an optimization for predictable workloads.
Defining access pattern entities
Identifying your data access patterns is key to designing a successful data model. We start by defining the entities and attributes in our data model, then document our access patterns.
In our example multi-tenant issue tracking application, we have the following entities and attributes:
Ticket
- TenantId – This is the customer (buyer) of our application. There are multiple tenants.
- TicketId – This is an auto-generated unique identifier for each ticket.
- Status – The current status of the ticket.
- Created Date – The date the ticket was created.
- Resolver – The current assigned resolver of the ticket.
- Title – The title of the ticket
- Created By – The user who raised the ticket
Comment
- CommentId – This is an auto-generated unique identifier for each comment.
- Created Date – The date the comment was created
- Created By – The user who added the comment
The following figure shows this as a traditional entity-relationship diagram (ERD).
Documenting access patterns
Now that you have modeled the entities, it’s time to document the access patterns. For simplicity, there are two personas in the application: a regular tenant user and a tenant admin user. Not all personas and access patterns may be known at this point.
The following are the access patterns for our example application:
- “As a user, I want to get a single ticket and all comments.”
- “As a user, I want to view a single ticket summary.”
- “As a user, I want to get all open tickets.”
- “As a user, I want to view all open tickets for a given resolver.”
- “As a user, I want to change the status of multiple tickets atomically.”
- “As a tenant admin, I want to view an aggregate of the tickets by status in my tenant.”
With the access patterns documented, to design the right data model, requirements such as frequency, requests per second, SLA, and consistency need to be collected for each access pattern. We document these requirements for the issue tracking application in the following table.
| Access Pattern | Peak Throughput (requests per second) | Frequency | Priority | Consistency Requirement | Persona |
| As a user, I want to get a single ticket and all comments. | 50 | Hourly | High | Eventual | User |
| As a user, I want to view a single ticket summary. | 100 | Hourly | High | Eventual | User |
| As a user, I want to get all open tickets. | 25 | Hourly | Medium | Eventual | User |
| As a user, I want to view all open tickets for a given resolver. | 25 | Hourly | High | Strong | User |
| As a user, I want to change the status of multiple tickets atomically. | 5 | Hourly | High | Strong | User |
| As a tenant admin, I want to view an aggregate of the tickets by status in my tenant. | 10 | Daily | Low | Eventual | Tenant Admin |
Table design for multi-tenant applications
Choosing a table design is a non-trivial decision and should be carefully considered. Our goal is to create an efficient data model for cost and performance. With multi-tenancy, any wastage scales with the number of tenants, so efficiency becomes a priority.
When choosing a table design, it’s important to work backwards from your access patterns and choose the best data model for your use case. Considerations for table design are covered in Data Modeling foundations in DynamoDB.
If your access patterns lead you to a single-table design, then you should consider whether the cost and performance efficiencies of a single-table design outweigh the simplicity of a multi-table one. Single-table design is an advanced pattern and should not necessarily be the default approach.
Conclusion
Designing a performant DynamoDB data model for multi-tenant applications requires careful planning and analysis. By starting with the core entities and access patterns of your application, you can make informed decisions about partitioning, isolation strategies, and table structure. Defining these requirements per access pattern ahead of time helps make sure the table can scale as the application grows.
To summarize the takeaways:
- Start by defining the entities and entity relationships inside your data model
- Document your access patterns
- Maintain a consistent data model across different tenant partitioning models
- Evaluate table design based on your application requirements
In this post, we discussed the requirements for building a multi-tenant DynamoDB table. In Part 2, you will learn about data modeling and implementing the access patterns defined in this post. In Part 3, you’ll validate your data model and explore how to extend the model as new access patterns emerge.
About the Authors
Dave Roberts is a Senior Solutions Architect in the AWS SaaS Factory team where he helps software vendors to build SaaS and modernize their software delivery. Originally from Aotearoa, he now lives in Germany with a loving wife and two kids. Outside of SaaS, he enjoys hearing the birds sing and hiding Easter eggs in technical content.
Josh Hart is a Principal Solutions Architect at Amazon Web Services. He works with ISV customers in the UK to help them build and modernize their SaaS applications on AWS.
Samaneh Utter is an Amazon DynamoDB Specialist Solutions Architect based in Göteborg, Sweden.
Source: Read More