Does anyone have any links/resources on how to do unique value reservations in an eventually consistent environment?
Example: Users, on signup, get to choose their username. Even if two users are trying to grab the same name at the same time, only one should succeed.
I've got a couple of potential solutions floating around my head, but I was wondering if anyone has already done the legwork for this design.
Uniqueness constraints require serializability/linearizability. That makes it impossible to achieve in a non-serializable system. All AP systems in the CAP sense are non-serializable.
Eventual consistency is vaguely defined but it almost almost implies a non-serializable system. Therefore, your request is impossible to achieve.
Chose a consistent database to get the uniqueness guarantees you need and potentially replicate that data into your eventually consistent data store.
This is one of those problems where the theoretical answer is just plain stupid. Yes, any unique identifier requires some form of serialization.
But in the real world it is very easy to extend an existing unique identifier to form a new one. The most obvious is your machine's public IP address and a timestamp. There can only be a single owner of an IP address at any time, therefore the combination is unique. You now just have to decide how many of these records you are allowed to create from one node in the precision of the timestamp.
Domain names also have the same characteristics, but are less compact. But they are more easily verified, which is why they are commonly used to form truly global namespaces for object classes.
When you mentioned the username field, you reminded me of an old viral joke stating that the greatest problem humanity will have to solve 50 years from now is finding an available username on the internet.
The issue you are mentioning in your comment has to do with locking and concurrent inserts which is detailed here: http://dev.mysql.com/doc/refman/5.0/en/locking-issues.html
Now, as far as I am aware, insert statements are cached and stored in a queue prior to be executed, regardless of their similar time of arrival. So automatically one will get the unique value (e.g: the username), while the other won't. But realistically, the odds to have two users choosing the same username at the same atomic time are very, very low. There are a lot of things that need to work perfectly in order to test that even in a laboratory environment.
On a different note you can allow two users to register while having the same username. For example: Assume that you have an user account system where you allow an user to register with a username and a password. The username is restricted to the following characters: a to z, A to Z, 0 to 9 plus the special characters _(underscore) and .(full stop). You can concatenate the username (which is defined as not unique in your mysql table) with a special character (excepting _ and .) followed by an unique identifier that you have in your mysql table (let's say the user_id).
When the user tries to login, you compare his input with the set of all substring usernames (you only take the value prior to the special character you defined). Record the matches in an array, then check to see if the user password matches with any of the found users' password. If it does, then you log him in, if it doesn't then you don't.
Although I've seen the above in practice, I am quite against it. I would use the users' e-mail instead of an unique username. It is a much simpler and much cleaner solution since the e-mail is unique. There are no two users that have the same e-mail account, unless they share that address (for example addresses that sound like contact@xyzcompany.com).
