How to create a short readable UUID in a microservices distributed environment

Question

I am working in breaking a super monolith web service into a microservices approach using CQRS and Event Sourcing. With that and considering previous architecture depending in SQL Server incremental identity numbers for each table it is unacceptable for a distributed system to rely in a database since we will now have various projections of the events in the system.

But we still have to keep relations and transfer ids around for analytics, API calls etc. The obvious option is GUID, and that looks fine until you come to the point of a GET request, http://awesomedomain.com/users/98e3b2ab-3c69-4077-aea1-38d22e79b007, hmm not that pretty and kind of cumbersome but it will work. It is also known that having GUID as index keys in a database can be a performance hit.

After looking some answers here to try and generate ids based on EPOCH UNIX timestamp ticks, shorten the GUID, or this interesting approach (but finding out not global solution), every solution will not really guarantee global uniqueness, except the short GUId one, but still not clear.

Another option would be to have a Guid Service with a distributed lock (Redis) to generate EPOCH UNIX tick id but that can give us a performance hit if you have thousands of concurrent "create" requests.

Should we really bother to shorten a GUID or find another solution that is more "human readable"? Are there any other solutions for global unique identifiers that we could implement?

Answer 1

What you have is good.

It may not be humanly readable but that is exactly what it should be. Sequential IDs are easily guessable and bad for security. GUIDs fill this gap pretty good.

Depending on how your system is structured you can actually have int IDs as primary keys while keeping your GUIDs too and they don't have to be primary keys. This is however not always possible.

Answer 2

It is very important to measure and research this requirement first. You definitely don't want to implement complex, hardly maintainable logic for object creation just to be able to handle more requests than your system would ever have.

I personally would say that database auto-increment keys and microservices are not mutually exclusive. You can have lots of instances of a lightweight service, all working with single microservice-specific database behind it. Even though it can make the DB connection a bottleneck or single point of failure, it is still viable and many services in the Internet work fine this way. If you design the database correctly and keep it "micro", then it should work fine, at least for "thousands of create requests".

It also really depends on the data you are working with.
If you create users, then I think that using IDs or user-specified usernames is more natural, than GUIDs.
If you create a platform where people upload content, which is not related to each other, then you might want to look into how YouTube implemented ID generation for its videos - just random IDs encoded as base-something, shorter than GUID and more readable for human eye.