should we just change the index projection to INCLUDE or ALL?

I'm not sure. DDB is outside my expertise. CC @bartek

It depends on how often we query by index (UserInfo a.k.a username) vs normal table primary key (userID) vs how many columns (attributes) the column has in total.

• Projecting ALL will technically duplicate the whole table in an index (2x storage).
• Querying a keys-only index and then re-query the table (done in this diff) consumes another RCU (read capacity unit) because we do 2 read requests instead of one.

In our case:

• If we query the users table often and/or it has only few columns, changing projection to ALL makes sense, because storage costs will be lower than query costs
• If the query is comparatively rare (to querying by id), then we can leave it as is.
• If query-by-username requires only some additional columns, not all, the INCLUDE is the way to go

If we added some monitoring (idk if aws has built-in tools precise enough), we can see in practice how it scales and change the approach later (note that it will need a migration: 1. create a new index, 2. switch code to use it, 3. delete the old one)

I suspect that query-by-username will be a common flow. Here are the situations in which it will happen:

1. When a user registers an account, we need to check if their selected username is already in use
2. When a user searches Comm, we need to search usernames
   • Current interface: chat composer. This will stay
   • Current interface: friend list and block list. This will stay
   • Current interface: search in chat list. This will be replaced by the next one
   • Future interface: global search

Additionally, it's important to call out that we will need "prefix search" for some of these use cases. Eg. we should be able to return "ashoat" if the user searches for "ash".

It may be the case that DDB is not a good option for solving this problem. I haven't thought about it deeply. The tasks for this are ENG-4131 and ENG-4132

In D8402#249035, @ashoat wrote:

I suspect that query-by-username will be a common flow. Here are the situations in which it will happen:

1. When a user registers an account, we need to check if their selected username is already in use

Okay, registration is common, but request rates still will be relatively low (we don't expect hundreds of registrations per minute)

2. When a user searches Comm, we need to search usernames
   • Current interface: chat composer. This will stay
   • Current interface: friend list and block list. This will stay
   • Current interface: search in chat list. This will be replaced by the next one
   • Future interface: global search

Additionally, it's important to call out that we will need "prefix search" for some of these use cases. Eg. we should be able to return "ashoat" if the user searches for "ash".

It may be the case that DDB is not a good option for solving this problem. I haven't thought about it deeply. The tasks for this are ENG-4131 and ENG-4132

Yeah, prefix search is DDB's weak part - we can do it only by "sort keys" which is not the case here. We would probably need a separate search engine for this purpose.

I think we can just stick with Jon's current approach here

For the searching usernames piece, I think we'll have to use AWS CloudSearch or Elasticsearch on top of DDB. https://docs.aws.amazon.com/cloudsearch/latest/developerguide/searching-dynamodb-data.html

Continuing on :)