Hey everyone! I'm working on a SaaS project using AWS services, specifically Lambda and DynamoDB, and I'm having a tough time designing the database schema. I need my app to support a few key features:
1. Users should be able to create posts with a post ID, user ID, description, and due date.
2. Users need to fetch posts between two specific dates.
3. Each user should have easy access to the posts they've created.
4. Users should be able to mark posts as favorites and view them.
Given that the main interaction is users logging in to see a feed (kind of like Facebook), it would be ideal for the frontend to fetch posts sorted by due date in ascending order.
I'm concerned about the 'hot partition' issue that can arise with heavy traffic (like if 10,000 users are clicking to load more posts at once). I've got a schema in mind, but I'm unsure if it's the right fit.
Here's what I'm thinking for the PostsTable:
- Primary Key: post_id
- Global Secondary Index (GSI): ALL_POSTS
- Attributes: due_date, user_id, etc.
I've also thought about daily shards for posts, but I'm worried about the inefficiencies if some days have no posts. Do you think DynamoDB is suitable for this type of application, or should I consider switching to a relational database? Any advice on how to structure this would be greatly appreciated! Thanks in advance!
4 Answers
Based on your requirements, it seems like DynamoDB might not be the best fit. Have you considered using Aurora DSQL? It's performance-oriented, scales down to zero when not in use, and charges based on consumption, similar to DynamoDB. It could handle your varied query patterns more effectively.
By the way, does it wake up instantly now? Some earlier versions had those delays when turning on.
Your design doesn't seem too complicated! For posts, just set it as PK/SK with id=Post#[user_id]/date, and have a GSI of type=Post/date for easier querying. For favorites, introduce a separate record type with PK/SK as Favorite#[user_id]/date. With AppSync and GraphQL, you can easily manage these lookups with pagination based on date for new records.
For your use case, I'd recommend shifting to a schema where you use user_id as the primary key and type/date for the sort key. This will allow you to have strongly consistent reads for items created or favorited by users. Additionally, consider creating buckets dynamically to manage queries better instead of relying on one global index for all posts. Something like this:
Table key: | post::
GSI key: ALL_POSTS/ | ::
This will help mitigate the hot partition issue you're worried about while still scaling with your needs.
You should definitely look into single table design in DynamoDB. There are some great resources by Alex DeBrie and Rick Houlihan on how to structure your data.
Totally agree! Your needs sound complex for Dynamo. Aurora could be a simpler and more efficient choice.