AWS DynamoDB for Serverless Microservices

DynamoDB is the Serverless NoSQL Database offering by AWS. Being Serverless makes it easier to consider AWS DynamoDB for Serverless Microservices since it goes inline with the patterns and practices while designing serverless architectures in AWS.

Are you still confused what a Serverless NoSQL Database means? Let me give you a quick overview. We use the term Serverless when we don’t need to manage any servers (Software Updates, OS Patching, OS Security & etc.), rather someone else manages them for us and provides an abstracted view. When it comes to DynamoDB, AWS manages the underlying infrastructure, software and provides us an abstract view of Tables, Indexes (GSI, LSI), Throughput, Auto Scaling and Security Policies, which consists of high-level constructs for the NoSQL database. The below diagram shows AWS DynamoDB configuration patterns.

AWS DynamoDB configurations

This article provides an overview of the principles, patterns and best practices while using AWS DynamoDB for Serverless Microservices.

Principles in Using AWS DynamoDB

AWS DynamoDB is more suited for storing JSON documents and use as a storage for key-value pairs. Having multiple types of indexes as well as multiple types of query possibilities makes it convenient to be used for different types of storage and query requirements. However, it is important to understand that DynamoDB is a NoSQL database which is difficult to be compared with a Relational Database, side by side. This also makes it really difficult to for a person who is coming from a Relational Database background to design DynamoDB tables. Therefore it is important to understand several underlying principles in using DynamoDB. The following list contains 12 principals I follow when designing DynamoDB tables and queries.

  1. Use GUID’s or Unique Attributes, instead of incremental IDs.
  2. Don’t try to normalize your tables.
  3. Having duplicate attributes in multiple tables is fine as long as you have implemented ways to synchronize the changes.
  4. Keeping pre-computed data upon updates is efficient with DynamoDB if you need to query them often.
  5. Don’t try to keep many relationships across tables. This will end up needing to query multiple tables to retrieve required attributes.
  6. Embrace eventual consistency.
  7. Design your transactions work with conditional writes.
  8. Design your tables, attributes, and indexes thinking of the nature of queries.
  9. Use DynamoDB triggers and streams to propagate changes and design event-driven data flows.
  10. Think about item sizes and using indexes effectively when listing items to minimize throughput requirements.
  11. Think about the growth of attribute data, to design whether to store them as a nested object or use a different table for it.
  12. Avoid using DynamoDB Scan operation whenever possible.

Patterns for Serverless Microservices

AWS DynamoDB is used for Serverless Microservices with different configuration patterns for various use cases.

Direct Access from RESTful API

Direct Access from Restful API

The most common pattern for Serverless Microservices is to connect DynamoDB to an API Endpoint Code (Inside AWS Lambda) which is invoked through AWS API Gateway. It is also possible to directly connect DynamoDB to API Gateway if the Microservice offers support for direct DynamoDB queries.

Note: It is also possible to invoke AWS Lambda as a RESTful endpoint if the client has AWS IAM credentials or AWS STS temporary credentials.

Event-Driven Updates

Event Driven Updates

DynamoDB also can be updated, based on events other than Direct Access from RESTful API. For example, DynamoDB can be used to store metadata of files uploaded to Amazon S3. Using S3 Upload Trigger, Lambda function can be invoked upon file upload which is able to update the DynamoDB table. A similar approach can be used to perform DynamoDB updates in response to  Amazon SNS.

Data Synchronization Between Microservices

Data Syncronizations between microservices

If there are same attributes stored in multiple Microservices DynamoDB tables, you can use Amazon Simple Notification Service (SNS) Topics. Using Amazon SNS it is possible to inform attribute changes from one service to another without each of them knowing each other.

For example, let’s say Service #1 Company Profile Table and Service #2 Company Statistics Table shared company name attribute. If the company name is modified in Service #1 that change needs to be propagated to Service #2 Company Statistics Table. Knowing these requirements, it is possible for Service #1 to publish the attribute change using DynamoDB Streams and a Lambda function to the SNS topic. When the change happens the Lambda function in Service #2 subscribed to the topic will update the Company Statistics Table.

Conclusion

If you are new to AWS DynamoDB, it is important to understand its capabilities and limitations before moving into the database design.  It is equally important to have a proper mindset to design the data model using NoSQL principals and configuration patterns. This will include unlearning some of the concepts learned from Relational Database Design. In addition, using DynamoDB can be really challenging for some use cases. If you are struggling to think of how to update multiple tables concurrently, querying multiple tables or limitations of indexes for your use case, these can be hints to revisit the original decision to use DynamoDB in the first place. However, AWS DynamoDB is an integral part of the AWS Serverless Technology Stack which still remains as the leading Serverless NoSQL database in AWS.

—END —

Share your views with us and don’t forget to follow us on Twitter and Medium  @totalcloudio.

Editorial Note: This awesome guest blog post is written by Ashan Fernando, Amazon Certified Solutions Architect Professional

Smart Scheduling at your fingertips

Go from simple to smart, real-time AWS resource scheduling to save cost and increase team productivity.

Learn More
More Posts

You Might Also Like

Product
Introducing the TotalCloud Smart Scheduler
Announcing the launch of the TotalCloud Resource Scheduler! Take complete advantage of AWS's 'pay for what you consume' model by putting a power control for every AWS resource that you use.
January 14, 2020
Sayonee
AWS Use Case Files
Increase AWS EBS Volume size (Auto-remediation)
Learn how a simple workflow can auto-remediate and increase the EBS volume size when disk utilization goes beyond 90%
December 2, 2019
Sayonee
AWS Use Case Files
Instance CPU Utilization Report
Learn how a single workflow can be used to generate a CPU Utilization Report for EC2 Instances. This enables you to stay on top of EC2 utilization efficiency, and ensure you aren't over or underutilizing them.
October 24, 2019
Sayonee
AWS Use Case Files
Lambda Daily Cost Predictor
Learn how a simple workflow can be used to predict daily lambda costs, that can help prevent 'bill-shocks' and optimize your costs better.
October 24, 2019
Sayonee
Cloud Automation
Putting DevOps on autopilot with LEGO-like automation
The post explains our flagship product, the TotalCloud Workflow Editor. The Editor assists you to do practically anything you want on your AWS infrastructure. It primarily enables you to create completely customized workflows from scratch to automate all cloud actions. Learn how to leverage the easy-to-use editor and save loads of time and costs.
October 24, 2019
Sayonee
AWS Use Case Files
Reporting Security Groups with TCP Port 22 (SSH) access from public IP
Learn how to use a simple workflow to generate a report of Security Groups with unrestricted Port 22 access from Public IP. Similarly, workflows can be generated to identify SGs with any open ports.
October 24, 2019
Sayonee