Currently, when a new pending report is uploaded, the upload token is allocated by generating a random number and retrying until an unallocated token is found. This works for testing, but is not what we need in the long run.
The actual token allocation scheme must retain the following property: When a new token is allocated, the numerically smallest token which is not currently allocated is chosen.
For the current version, we may be able to rely on Firestore's strong consistency model to make this easier. However, we should keep in mind that if we migrate off of Firestore in the future and onto another NoSQL database, that database may not have the same consistency model, and so we may need to design another scheme, possibly incorporating a SQL database into our infrastructure in order to support token allocation.
Currently, when a new pending report is uploaded, the upload token is allocated by generating a random number and retrying until an unallocated token is found. This works for testing, but is not what we need in the long run.
The actual token allocation scheme must retain the following property: When a new token is allocated, the numerically smallest token which is not currently allocated is chosen.
For the current version, we may be able to rely on Firestore's strong consistency model to make this easier. However, we should keep in mind that if we migrate off of Firestore in the future and onto another NoSQL database, that database may not have the same consistency model, and so we may need to design another scheme, possibly incorporating a SQL database into our infrastructure in order to support token allocation.