DynamoDB

Overview

This topic explains how to use the SDK DynamoDB integration as a persistent feature store.

Many of our server-side SDKs support DynamoDB. DynamoDB is a particularly useful solution if you are running code in AWS Lambda, because you can access it from Lambda without needing access to any VPC resource.

Setup and permissions

In your application code, the only required parameter is the table name, although you can also specify any other options supported by AWS. By default, the DynamoDB driver expects to get your AWS credentials and region from environment variables or local configuration files, as described in the AWS SDK documentation.

The table must already exist before your application starts. It must have a partition key called "namespace", and a sort key called "key". The SDK does not create the table automatically because it would not know what values to use for other properties such as permissions and throughput.

DynamoDB imposes a limit of 400KB on the total size of any database item. In this implementation, each feature flag or segment is a single item, so the feature store is not able to persist any flag or segment whose JSON representation is larger than that limit.

For a process to read from the DynamoDB table, it needs the following permissions:

• GetItem
• Query

For a process to write to the DynamoDB table, it needs the following permissions:

• PutItem
• UpdateItem
• DeleteItem
• BatchWriteItem
• ConditionCheckItem

In some situations your process may only need the read permissions. For example, if you use the Relay Proxy, then only the Relay Proxy will write data to the table. In this case, the Relay Proxy will likely use permissions from a different role.

How the SDKs store data in DynamoDB

The DynamoDB integrations for all LaunchDarkly server-side SDKs use the same conventions, so that SDK instances and Relay Proxy instances sharing a single DynamoDB table can interoperate correctly.

The storage schema is as follows:

• For each data item that the SDK can store, such as a feature flag, there is a single DynamoDB data item, with the following attributes:
  • namespace: a string value with a KeyType of HASH that denotes the type of data, such as features and segments. Or, if you have specified a prefix string, the namespace is set to PREFIX:TYPE where PREFIX is your configured prefix and TYPE is the type of data.
  • key: the unique key of the item, such as the flag key for a feature flag, with a KeyType of RANGE.
  • version: a number that the SDK uses to keep track of updates.
  • item: a serialized representation of the data item, in a format that is determined by the SDK.
• An additional item with a namespace of $inited or PREFIX:$inited is created when the SDK has stored a full set of feature flag data. This allows a new SDK instance to check whether there is already a valid data set that was stored earlier.
• If you have specified a prefix string, the SDK never adds, modifies, or removes any items in the DynamoDB table that do not have a namespace starting with PREFIX:, so it is safe to share a DynamoDB table that is also being used for other purposes.

Server-side SDKs

In the following examples, the DynamoDB feature store is set to use a table called "my-table" and a cache TTL of 30 seconds. The DynamoDB feature store does support using a key prefix, as shown in the Redis examples, but it is uncommon for one DynamoDB table to be shared by multiple applications.

This feature is available in the following server-side SDKs:

• .NET (server-side)
• Go
• Java
• Node.js (server-side)
• PHP
• Python
• Ruby

.NET (server-side)

Go

Java

Node.js (server-side)

PHP

Python

Ruby