3 ms·
Eh, what's the real likelihood of collision anyways? There can only be so many people that want a specific username out there that are going to be registering
by icey 17y ago
Eh, what's the real likelihood of collision anyways?
There can only be so many people that want a specific username out there that are going to be registering in the same few seconds or few minutes it takes before your data syncs up.
Unless you really have a compelling reason to do all this stuff, it kind of sounds like you're over-engineering it to me.
Why can't you just have 1 registration server and call out to it asynchronously? Even across the globe you're talking about a delay of less than a second.
- pfarrell 17y agoWe've had issues with single points of failure and are trying to plan for failover and load balancing. I won't argue that this might be overengineered, but this is a full transactional application with 99.9% uptime guaranteed to our clients and with millions of transactions (mostly API) per hour. I agree this is a write-seldom, read-often piece of data. We route based on userid, so we can not have any chance for data collision.
- pfarrell 17y agoAlso, and I didn't make this explicit in my OP, we have identity collision issues (as indicated in the Flickr link from Travis) that are playing on our design as well. Thanks for the help icey