If you are worried about the over head of malicious bulk registration, you could develop some rate limiting to restrict the sign ups to X signups per hour from the same IP. Also you could use a CAPTCHA system to make lots of requests hard to create.
The other thing that works well is automating the clean up. We do an initial insert into the Users and UsersByEmail tables with a TTL of 12 hours. Only when they complete the signup do we redo the insert without a TTL making the data permanent. That works as a security measure and cleans up failed account creation at next compaction. We also have some counters so we can keep track of failed / successful registration ratios. Hope that helps, Charlie M On Wed, May 7, 2014 at 12:19 AM, Tyler Hobbs <ty...@datastax.com> wrote: > > On Mon, May 5, 2014 at 10:27 AM, Ignacio Martin <natx...@gmail.com> wrote: > >> >> When a user registers, the server generates a UUID and performs an INSERT >> ... IF NOT EXISTS into the email_to_UUID table. Immediately after, perform >> a SELECT from the same table and see if the read UUID is the same that the >> one we just generated. If it is, we are allowed to INSERT the data in the >> user table, knowing that no other will be doing it. >> > > INSERT ... IF NOT EXISTS is the correct thing to do here, but you don't > need to SELECT afterwards. If the row does exist, the query results will > show that the insert was not applied and the existing row will be returned. > > > -- > Tyler Hobbs > DataStax <http://datastax.com/> >
