Patterns

The following patterns were chosen following the best DynamoDB practices and with the business needs in mind. Some are for standardization among all the application

• Attribute names have no relationship to attribute values.
• Store date-like data as integers, for easy comparison.
• Automatic UUID generation for ids. When the attribute must have an id (this is not applicable to available_groups since it is a simple string value), it should be an uuid4.
• According to official documentation the latency of a get_item vs a query limit=1 will be equivalent. So it is better to have always both range and sort key for every table and GSI.
• Use hierarchical relationships: group attributes will have an attribute, which is a sort key, with the following structure: ORG_ID#TYPE#STATUS. With this, it is easy to search for groups within a company, with a certain type in a given status, and everything in between, since a sort key can be searched partially.

Calculations for write sharding:

ItemsPerRCU = 4KB / AvgItemSize

PartitionMaxReadRate = 3K * ItemsPerRCU

N = MaxRequiredIO / PartitionMaxReadRate

For groups. Get active and suspended groups. This query is important for forces executions:

10000 projected groups
(more than fi\_projects + fi\_project\_names)
in the following 5 years
Currently, there are 594 projects,
with a total size of 1.55MB (1'550.000 bytes)
At least 30% will be active-suspended, so:
MaxRequiredIO = 0.3 \* 10000 = 3000
2609 bytes per item
ItemsPerRCU = 4KB / 2.6KB = 1,54
PartitionMaxReadRate = 3000 \* 1,54 = 4.6K
N = 3000 / 4.6K = 0,65

Given the latter, there is no need to write sharding in groups items

For findings.

• NoSQL Design
• Partition Key Design
• Sort Key Design
• Secondary Indexes
• Many-to-Many Relationships
• Relational Modeling