Designing DynamoDB Table w/ AppSync

Personally, I would put aside any single-table vs multi-table concern - honestly, 90% of the narrative around that distinction is fictional. Much of the associated guidance will lead you down a very painful path. If you really want to understand what's important in data modeling for DynamoDB, and the valid part of "single table design" and its history, here's a blog series you can read through: https://blog.highbar.solutions/series/ddb-data-modeling

Start by thinking about the types of entities/records you need to work with, which of them will need to be uniquely identified, and how you'll need to access them.

Hearing about your application, I think you have two different types of uniquely identified entities.

1/ Each user - I would recommend uniquely identifying them using something like a UUID. They will probably also need a username, and you may want them to be able to change their username as they please (without messing up any chat history they may already have). So make the username another attribute in that user's record so it's easy to update without changing the unique identifier for their record.

2/ Each chat - it isn't clear to me whether each pair of users have just one 1:1 chat, or if the same two users can have multiple distinct chats/rooms. In any case, I would construct the unique identifier by combining the two user UUIDs, and (optionally) another UUID for the room. Now the messages in the chat can be inserted in a sorted order (by timestamp, most likely - as you've detailed above).

For #1, these records are likely to remain small and bounded in size, so a single item per user is fine - use a table with a simple primary key: just a partition key, no sort key necessary.

For #2, these records are going to grow over time, and could become quite large. It's easiest to manage new messages in the chat by adding them without having to rewrite the entire chat history. So, use an item collection (a set of items which all have the same value of partition key, but unique sort key values). You'll need a table for this which has a composite primary key (partition key + sort key).

That's the basis of your data model. As you think it through more, you'll find some secondary access patterns. You can add GSIs to cover these. For example, you'll need to find all the chats for a particular user, so when they login they can see them listed and move between them as needed. If you allow multiple rooms for each pair of users, you might find you want to add another type of entity for the room itself - perhaps identifying it uniquely by a UUID, with an easily editable room name (similar to the users). You can extend and expand from here as your application needs dictate.

I'm not a GraphQL/AppSync expert, but I think looking at your access patterns above as you develop your DynamoDB data model will help you to easily see which resolvers you need. These two technologies really do fit together quite beautifully.