You're off to a great start by thinking deeply about your access patterns and defining your entities (Posts, Users, Likes, etc). As you know, having a thorough understanding of your access patterns is critical to storing your data in DynamoDB.

While reviewing my answer, keep in mind that this is only one solution. DynamoDB gives you a ton of flexibility when defining your data model, which can be both a blessing and a curse! This answer is not meant to be the way to model these access patterns. Instead, it's one way that these access patterns can be implemented. Let's get into it!

I like to start by listing the entities we need to model, as well as the Primary key for each. Throughout this post, I'll be using composite primary keys, which are keys made up of a Partition Key (PK) and a Sort Key (SK). Let's start out with a blank table and fill it out as we go.

         Partition Key             Sort Key
User
Post
Tag

Users

Users are central to your application, so I'll start there.

Let's start by defining a User model that lets us identify a User by ID. I'll use the pattern USER#<user_id> for the PK and SK of the User entity.

This supports the following access patterns (examples in pseudocode for simplicity):

1. Fetch User by ID

ddbClient.query(PK = USER#1, SK = USER#1)

I'll update the table with the new PK/SK pattern for Users

         Partition Key             Sort Key
User     USER#<user_id>           USER#<user_id>
Post
Tag

Posts

I'll start modeling Posts by focusing on the one-to-many relationship between Users and their Posts.

You have an access pattern to fetch All Posts by UserId, so I'll start by adding the Post model to the User partition. I'll do this by defining a PK of USER#<user_id> and an SK of POST#<post_id>.

This supports the following access patterns:

1. Fetch User and all Posts

ddbClient.query(PK = USER#<user_id>)

2. Fetch User Posts

ddbClient.query(PK = USER#<user_id>, SK begins_with "POST#")

You may wonder about the odd-looking Post IDs. When fetching Posts, you'll probably want to get the most recent Posts first. You also want to be able to uniquely identify Posts by ID. When you have this sort of requirement, you can use a KSUID as your unique identifier. Explaining KSUID's is a bit out of scope for your question, but know that they are unique and sortable by the time they were created. Since DynamoDB sorts results by the Sort Key, your query for a user's posts will automatically be sorted by creation date!

Updating the PK/SK patterns for your application, we now have

         Partition Key             Sort Key
User     USER#<user_id>           USER#<user_id>
Post     USER#<user_id>           POST#<post_id>
Tag

Tags

We have a few options on how to model the one-to-many relationship between Posts and Tags. You could include a list attribute on your Post item, which simply lists the number of tags on the item. This approach is perfectly fine. However, looking at your other access patterns, I'm going to take a different approach for now (it will be apparent why later).

I will model tags with a PK of POST#<post_id> and an SK of TAG#<tag_name>

Since Primary Keys are unique, modeling tags in this way will ensure that no Post is tagged with the same Tag twice. Additionally, it allows us to have an unbounded number of Tags on a Post.

Updating our PK/SK table for Tag, we have

         Partition Key             Sort Key
User     USER#<user_id>           USER#<user_id>
Post     USER#<user_id>           POST#<post_id>
Tag      POST#<post_id>           TAG#<tag_name>

At this point we've modeled Users, Posts and Tags. However, we've only addressed one of your four access patterns. Lets see how we can use secondary indexes to support your access patterns.

Note: You could also model Likes in the exact same way.

Defining A Secondary Index

Secondary indexes allow you to support additional access patterns within your data. Let's define a very simple secondary index and see how it supports your various access patterns.

I'm going to create a secondary index that swaps the PK/SK patterns in your base table. This pattern is called an inverted index, and would look like this:

All we've done here is swapped the PK/SK pattern of your base table, which has given us access to two additional access patterns:

1. Fetch Post by ID

ddbClient.query(IndexName = InvertedIndex, PK = POST#<post_id>)

2. Fetch Posts by Tag

ddbClient.query(IndexName = InvertedIndex, PK = TAG#<tag_name>)

Fetch All Posts by Public/Private status

You wanted to fetch posts by public/private status, as well as fetching all Posts. One way to fetch all Posts is to put them in a single partition. We can put the public/private status in the sort key to separate the public and private Posts.

To do this, I'll create two new attributes on the Post item: _type and publicPostId. These fields will serve as the PK/SK patterns for the secondary index I'm calling PostByStatus.

After doing this, your base table would look like this:

and your new secondary index would look like this

This secondary index would enable the following access patterns

1. Fetch All Posts

ddbClient.query(IndexName = PostByStatus, PK = POST)

2. Fetch All Private Posts

ddbClient.query(IndexName = PostByStatus, PK = POST, SK begins_with "PRIVATE#")

3. Fetch All Public Posts

ddbClient.query(IndexName = PostByStatus, PK = POST, SK begins_with "PUBLIC#")

Remember, post ID's are KSUID's, so they will naturally be sorted in your results by the date the Post was made.

A Word on Hot Partitions

Storing all your Posts in a single partition will likely result in a hot partition as your application scales. One way to address this is by distributing your Post items across multiple partitions. How you do that is entirely up to you and specific to your application.

One strategy to avoid the single POST partition could involve grouping Posts by creation day/week/month/etc. For example, instead of using POST as your PK in the PostByStatus secondary index, you could use POSTS#<month>-<year> instead, which would look like this:

Your application would need to take this pattern into account when fetching Posts (e.g. start at the current month and go backwards until enough results are fetched), but you'd be spreading the load across multiple partitions.

Wrapping Up

I hope this exercise gives you some ideas on how to model your data to support specific access patterns. Data modeling in DynamoDB takes time to get right, and will likely require multiple iterations to make work for your specific application. It can be a steep learning curve, but the payoff is a solution that brings scale and speed to your application.