It has been a long, long time since I first used UUIDs in a project. Back then I was not 100% sure what a UUID was; I didn’t even have a good reason for using it in the first place. Almost everyone that I knew, who was working with in PHP apps or with popular CMSs, was using auto-increment ids.
Time flies and 7 years fast forward, I am always using UUIDs and whenever I’m interviewing developers I cannot avoid asking them about UUIDs. Most of the times I’m surprised by the fact that many of them still don’t have a good reason for using UUIDs in their applications.
So, I thought it would be useful - at least for some of you - to share my experience regarding the usage of UUIDs in real-life application software.
UUID stands for Universally Unique Identifier. The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination.
UUIDs, as their name denotes, are Universally Unique. Well... even though this isn’t 100% accurate, however’, the probability of unintentionally, identifying multiple “entities” with the same value is so tiny that we can say that they are.
Furthermore, UUIDs can be considered to be a “value" and for developers that matters a lot, as we can generate that “value” everywhere via code.
So far we can sum up with the following points:
We can now say that the usage of UUIDs could help us to merge or shard a Database, given that there is no central coordinator regarding generation of those values. Those unique values are coming arbitrarily from everywhere…
But is it only about splitting or merging storages? As long as UUIDs are generated via code it can benefit you as a Software Engineer because they don’t block operations within your code.
Here are a few examples:
Let’s assume that you’re working on a booking engine project. When a customer books a flight, she/he receives an email with her/his booking id. When using with auto-increment ids (generated as primary keys in your DB), you always have to wait for the DB to respond in order to get the id and proceed with sending the email. In the case that DB fails to store the record, then your system is blocked… By using UUIDs you can do whatever you like with customers’ bookings, no matter where or when you are going to persist the booking. You can send an email and/or you can enque the booking in a queuing system for async processing without caring at all about the storage.
Let’s also assume that the booking application enables you to review hotels. Reviews is a one-page application that consumes a RESTful API. By using UUIDs, you can fully create the review on your javascript front-end application and then create that review on backend by sending a PUT request to the API. In short, with the usage of UUIDs you can take advantage of every REST API method and this way it’s easy to make you app operate even in an offline mode!
Remember: PUT method in RESTful APIs, can also be used to create a resource in the case where the resource ID is chosen by the client instead of the server.
According to RFC 4122, we have several versions of UUIDs. Some of those versions contain extra information that could be very useful for developers. Versions 1 and 2 for example, contain creation datetime. You could use this information to take some datetime decisions in any of you applications.
There are also developers who are using UUIDs in order to prevent exposal of internal information. An auto-increment id in any URL could give the end user an idea of how many entities are in your storage or whether there is a security risk.
Well, the only concern could be about the performance when inserting UUIDs in your Database. In general, UUIDs degrade database performance. However this is an issue that I prefer to touch upon in later posts where I will be sharing some techniques that help you take advantage of the usage of UUIDs without degrading your database performance.
Stay tuned!
PS: Feel free to share your experience regarding the usage of UUIDs by commenting under this article!