💽 Dynamo Infrastructure
This file is responsible for setting up a DynamoDB NoSQL Database table following the single table design pattern.
Reason for using DynamoDB
NoSQL databases were designed to handle high-scale applications that relational databases could not handle. To do this, NoSQL databases removed some features from relational databases that were sources of slowness, like joins and aggregations.
With DynamoDB your performance won't degrade over time, even if your application scales to 1000x the original size. And the best part is, that DynamoDB is a fully serverless managed service, so you don't have to worry about the underlying infrastructure at any time.
Single Table Design
A single table design in DynamoDB involves using a single table to store multiple types of entities. This design leverages the flexibility of DynamoDB's schema-less nature and its powerful indexing capabilities to efficiently handle various access patterns within a sin
A single table design is superior for scalability and cost efficiency because:
- Scalability: A single table scales horizontally, handling large data volumes and high request rates seamlessly.
- Cost Efficiency: Optimizing access patterns in a single table reduces read/write operations and saving costs
Here's (opens in a new tab) a great ressource explaining the single-table design pattern in more detail.
We use an ORM called electroDB (opens in a new tab) which automatically handles all complexities of the single table design pattern in a type-safe manner.
It's a library to ease the use of having multiple entities and complex hierarchical relationships in a single DynamoDB table, and also provides easy-to-use type-safe access methods.
Conviniently, I already includes some example code to get you started. Checkout the packages/core/src/database/entities/EmployeeEntity.ts file, to see how we use electroDB to define our business entities.
Indexes in DynamoDB
DynamoDB indexes are mechanisms to allow efficient querying of data. You can define dozens of them on a single table, however, in most cases you will only need a few. Here we define three indices on our table, which should be enough to cover a large number of access patterns. See the AWS documentation (opens in a new tab) for more information.
Primary Table
Blitship already sets up a DynamoDB table for you, which will hold most off you primary application data. It's configured with the following attributes:
- Billing Mode:
PAY_PER_REQUEST, allowing you to pay only for the read and write requests you use. - Stream:
NEW_AND_OLD_IMAGES, enabling real-time data processing by capturing both the new and old images of the items. - Time-to-Live Attribute:
expires, which allows automatic deletion of expired items.
Additional Features
DynamoDB is great for storing and retrieving application data, but it's not so great for searching and analyzing on top of it.
If you need to search your data, you should use full-text search services like ElasticSearch of Meilisearch to provide full-text search capabilities on top of your DynamoDB table.
For that you can easily implement a stream to direct all changes from your DynamoDB table to a Meilisearch index. In the codebase you find a commented out example of how you would do that.