5

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?

George Taskos
  • 8,324
  • 18
  • 82
  • 147

3 Answers3

4

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.

Andrei Dragotoniu
  • 6,155
  • 3
  • 18
  • 32
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.

Yeldar Kurmangaliyev
  • 33,467
  • 12
  • 59
  • 101
  • 1
    I agree with natural keys like Stefan mentioned in his answer, but not a fan of auto-incremental IDs in any case since I have to insert a record to get an ID and like Andrei mentioned is easily hackable. But yes, your point is taken and is valid. – George Taskos May 04 '19 at 21:20
  • You are 100% right about object creation complex logic. Frankly a timestamp tick id and natural keys should work fine at the end of the day. – George Taskos May 04 '19 at 21:27
1

There are a couple of options you can pick from:

don't care

Why bother about the GUID. Nobody is going to see it. It's only used for service to service communication or technical api calls.

Downside: can look ugly.

use natural keys

Things can have ISO standards, like countries, or currencies. They are human readable in most cases. Some other things can have another natural identifier, like ships.

Some things don't. That's annoying. No downsides (beside speed of db calls), but not always available.

reformat ID locally

Some UI web part might store some super fast searchable entries in it's own search optimised database. Here you can have a local ID. But, this communicates badly with the other services.

Downside: integration complexity.

shorter guids

We can generate a random number can we? Better human readable. Nicer URLs. Cool.

Downsides: not much, just; no relation with actual entity. But, since you where using GUIDs you hadn't have it to begin with.

Of course I left some options out of the equation. Basically; all depends on your requirements. Speed, security, replication possibilities, etc. :-)

Enjoy!

Stefan
  • 17,448
  • 11
  • 60
  • 79
  • I like the natural keys where valid. Only problem is business is not that straightforward, we might have to create a user without any personal standard information. But answer is very helpful :-) – George Taskos May 04 '19 at 21:22
  • Yes, I admit, concerning users it's not wise to use a natural key. I tried to sum the general possibilities. I left out the auto increment; although in your case less likely to be applicable, for other purposes it could be. I am glad to see you take special precautions handling your user data. – Stefan May 04 '19 at 21:30