Modeling an invite schema with embedded collections with dynamodb or docuemntdb

Question

I'm investigating whether to use AWS DynamoDb or Azure DocumentDb or google cloud for price and simplicity for my app and am wondering what the best approach is for a typical invite schema.

An invite has

• userId : key (who created the invite)
• gameId : key
• invitationList : collection of userIds

The queries I would be running are

1. Get invites where userId == me
2. Get invites where my userId is in the invitationList

In Mongo, I would just set an index on the embedded invitationList, and in SQL I would set up a join table of gameId and invited UserIds.

Using dynamodb or documentdb, could I do this in one "table" or would I have to set up a second denormalized table one that has an invited UserId per row with a set of invitedGameIds?

eg

A secondary table with

• InvitedUserId : key
• GameIds : Collection

Answer 1

Similar to hslriksen's answer, if certain criteria are met, I recommend that you denormalize all of this into a single document. Those criteria are:

1. The invitationList for games cannot grow unbounded.
2. Even if it's bounded, will a maximum length array fit in the document and transaction limits.

However, different from hslriksen, I recommend that an example document look like this:

{
  gameId: <some game key>,
  userId: <some user id>,
  invitationList: [<user id 1>, <user id 2>, ...]
}

You might also decide to use the built-in id field for games in which case the name above is wrong.

The key difference between what I propose and hslriksen is that the invitationsList is a pure array of foreign keys. This will allow indexes to be used for an ARRAY_CONTAINS clause in your query.

Note, in DocumentDB, you would tend to store all entity types in the same big bucket and just distinguish them with a string type field or slightly better, an is_my_type boolean field.

Answer 2

For DocumentDB you could probably just keep this in one document per inviting user where the document Id could equal the key of the inviting user. If you have many games, you could use gameId as partitionKey.

{ 
  "id" : "gameKey+invitingUserKey",
  "gameKey" : "someGameKey",
  "invitingUserId": "key",
  "invites": ["inviteKey1", "inviteKey2"]
}

This is based on a limited number of invites for a user/gameKey. It is however hard to determine the structure without knowing your query patterns. I find that the query patterns often dictates the document structure.