Building social features using DynamoDB and Lambda
--
Last month, we added some simple social features to Street Art Cities. These allow you to follow any entity on the platform (cities, artists, users), view a personalised feed of items related to those entities, and be notified when new items from entities you follow are posted.
Street Art Cities is built as a set of serverless services on AWS Lambda and DynamoDB, and figuring out the best architecture for this new functionality was a lot of fun.
Single-table design
Street Art Cities runs on a single DynamoDB table with about two dozen different entity types. For the new social functionality, we introduced two new ones: Follow and Activity.
I tend to use Google Sheets or something similar to figure out how these entities should be laid out across the indexes in the table in a way that works with our access patterns. For these new entities, this looked roughly like this:
The following access patterns were kept into account:
Follow
- Get list of followers of entity:
pk=follow#user_{me} - Get list of followed entities:
type=Follow, sk={me}
Activity
- Get activities for specific entity:
pk=activity#user_{userId} - Get activities for people I follow:
type=Activity, sk begins with {me}
This pattern allowed enough flexibility to easily fetch user-related activities and followers, but also to extend it to following cities, artists and other entities we might introduce in the future.
Activity fan-out
As part of making activities available for all followers of a certain entity, we need to create multiple copies of that activity for each recipient. This creates a lot of overhead in terms of number of rows, but for the scale of our platform, and with the fact that DynamoDB scales quite gracefully, this is a worthwhile trade-off that has the following benefits:
- Near-instant feed updates for a user — when a new…
