Since DynamoDB’s release in 2012, I have used it in simple scenarios, as a persistent key-value store, but never got into the best practices and design patterns that could let me maximize the benefits of it. As most of AWS technologies, Dynamo evolved, and now it offers more, such as transactions, range-based partitioning, and more native integrations with other AWS services.
Well finally, I had a good use case, a business capability (service) that needs a NO-SQL type of storage that can scale, but as an AWS customer, I had more options to choose from to be fair. As a note, the service I am building had some unknowns; expected high spikes on certain days of the week, with extensibility in mind for the future if it grows as expected. with that in mind, the choice went as below:
DynamoDB from our stoplight chart above, will be the best candidate to move forward, The next step is to explore “the how”, using Single Table Design.
Single-Table is a concept for utilizing DynamoDB’s design under the hood to connect all data needed in one table for a business capability, making use of well-thought of access patterns, for maximum performance and efficiency. you can learn more here.
To understand more if my use-case fits the bill, I needed to understand how DynamoDB stores the data. For it to be highly available, scalable, with a single digit latency, my service has to abide by the way Dynamo is designed.
Quick Overview — Basics of Dynamo
DynamoDB keeps your data in partitions (SSD under the hood), with Partition Key being the identifier of a record, the decision in which partition it goes, happens through a hash function. Optionally you can add a Sort Key, which is helpful to introduce to your records, as DynamoDB is able to order your records by it in ascending order in the same partition, makes the trip to grab your data much shorter.
Read/Write Patterns
In our use-case, I needed a breakdown of my application’s read/write patterns, this way I am able to translate it to what will be the records in my Dynamo Table.
- Customer needs to be able to view invoice details.
- Customer needs to be able to create/view transactions (charges/refunds) on an invoice.
- Customer needs to be able to view each transaction individually.
- Customer needs to be able to create/view comments on an invoice.
From my user stories, it is obvious that invoice number is the best candidate to be the Partition Key in our table, solving for other scenarios utilizing the Sort Key for more ways to access the data as shown above.
To give an example of how a combination of partition key and a sort key brings us back the data we need, I wanted to visualize it as below depending on AWS docs.
The benefits of DynamoDB as mentioned before are many, but one of the most important ones, is the flexibility it gives Tech and Engineering to respond to the business direction change or any demand, scenarios such as:
- I need to send the data to our data warehouse to analytics (Dynamo -> Streams -> RedShift) or (Dynamo -> S3 -> Data Warehouse)
- I need to be able to send emails on updates/deletes/inserts (Dynamo -> Dynamo Streams -> Lambda -> SeS) or (Dynamo -> TTL Field -> Lambda -> SES)
With this single table design, we were able to implement a service that is performant, price efficient, and extensible in the future with all the integrations that Dynamo comes with.
Top comments (0)