Hey everyone! I'm currently in the process of building a SaaS application on AWS, utilizing services like Lambda and DynamoDB. I'm stuck trying to figure out an optimal schema for my DynamoDB table for managing user posts. My requirements are as follows:
1. Users can create posts containing fields like post_id, user_id, description, and due_date.
2. Users should be able to fetch posts between two specific dates.
3. Each user should retrieve the posts they have created.
4. Users need an option to mark posts as favorites and view them.
The most frequent action will likely be users logging in and being redirected to a feed page, where they will see posts sorted by ascending due_date. I'd like to paginate this feed to show 20 items per click.
However, I'm concerned about potential hot partition issues if I have, say, 10,000 concurrent users clicking next. Currently, I have a table schema in mind, but I'm worried it might create problems. Specifically, I'm considering if shifting to a relational database would be better for this use case rather than sticking with DynamoDB. Any insights or advice? Thanks in advance!
5 Answers
This doesn't sound too complex! Just set up your PK/SK format as id=Post#[user_id]/date, and use a GSI of type Post/date. For favorites, introduce a new record type with PK/SK as id=Favorite#[user_id]/date. If you combine this with AppSync + GraphQL, you can handle pagination smoothly based on the current date and offsets.
Check out the single table design concepts for DynamoDB. Alex DeBrie and Rick Houlihan have some great resources on that topic that could provide you some guidance.
From what you've described, I think your query requirements might not align perfectly with DynamoDB's strengths. Have you considered using Aurora with DSQL? It offers performance that scales down to zero and is pay-per-use, similar to DynamoDB, but might fit better for your needs.
Does Aurora still have the delay when starting up like older versions, or is it more efficient now?
For your querying needs, you might want to implement a primary key based on user_id and then a sort key using the date/type. That way, you can manage reading user-created and favorite items more effectively. Consider creating buckets for better query control, like:
Table key: | post::
GSI key: ALL_POSTS/ | ::
Just keep in mind that if multiple users are trying to read the same posts at once, you'll need some additional strategies to avoid hot partitions, especially if 10k concurrent users are expected.
Your primary key (PK) should ideally be a unique identifier. I recommend using post_id as a UUID. For your sort key (SK), try something like {poster_id}#{epoch_timestamp_ms}. This structure would make it easier to fetch user-specific posts within date ranges. If favorites are important, consider adding a GSI for that feature. Otherwise, a set attribute that holds favorite post IDs could be useful for retrieving them quickly.
Yeah, it sounds like switching to Aurora could really help. This setup just seems too complicated for DynamoDB as it is.