I do not understand exactly how does having 2 separate tables - a “used” and a “not used” help solving the concurrency issue as written in the article ?
Type your question above this line.
Course: https://www.educative.io/collection/5668639101419520/5649050225344512
Lesson: https://www.educative.io/collection/page/5668639101419520/5649050225344512/5668600916475904
Hello @Parth_Patni
Key Generation Service (KGS) is a standalone service (that the design proposed) to generate random six-letter strings beforehand and store these keys in a database. KGS uses two tables to handle concurrency problems:
Servers can use KGS to read/mark keys in the database. KGS can use two tables to store keys: one for keys that are not used yet, and one for all the used keys. As soon as KGS gives keys to one of the servers, it can move them to the used keys table. KGS can always keep some keys in memory so that it can quickly provide them whenever a server needs them.
The discussion around two tables was to solve the read concurrency. The problem we are trying to solve is to not give the same key to two servers (as we don’t want two URLs to have the same short key). For this, as soon as the KGS read some keys, it moves them to the other table (or can simply store the last key that it has read). This will ensure that no two URLs get the same key.
For writes, we don’t have a concurrency problem, as there is only one KGS in the system at any time, to generate new keys.
Hope this clarifies.