Okay, things aren’t going quite to plan with getting this transition to microservices example written. Today’s isn’t the promised code either, but it is a concept that we need to do this transition.
Too many web frameworks use auto-incrementing integers as identifiers. It sort of works when you have a single application, but it doesn’t set you up well to work in a distributed system.
And that’s because endpoints in a distributed system need to be idempotent. For something to be idempotent, that things caller has to be what generates identifiers. That’s really hard to do if you have auto-incrementing integers.
A sequence like that has to be controlled from a single point. If you make everything in your system call into a single point to get an identifier, then you’re going to have a lot of network chatter to get those IDs. Or you could just let your callers guess at an ID, find out that they came up with a duplicate, and try again. That seems worse.
This is why we use UUIDs in Eventide and other microservices-based projects. UUID stands for “universally unique identifier.” You might have heard them called GUIDs, if you’re from Microsoft land. That stands for “globally unique identifier.” Now that we have rovers on Mars, “globally” unique isn’t good enough, so you have to use UUIDs.
That was a joke that plays out worse over text than it does in person. I’ll show myself out…
For our purposes today, there is not a material difference between UUIDs and GUIDs. They have a great advantage that the likelihood of randomly generating a collision is effectively 0 given the age of our universe. This means that callers can freely generate them without much risk of collision.
That means that callers don’t have to go to some central sequence to get identifiers to be idempotent.
