~

There are many use cases where we need to use a unique ID. In my experience, I only encouter 2 cases:

• ID to trace request from client to server, from service to service (microservice architecture or nanoservice I don't know).
• Primary key for database.

In my Go universe, there are some libs to help us with this:

• google/uuid
• rs/xid
• segmentio/ksuid
• oklog/ulid

The ID is used only for trace and log. If same ID is generated twice (because maybe the possibilty is too small but not 0), honestly I don't care. When I use that ID to search log , if it pops more than things I care for, it is still no harm to me.

My choice for this use case is rs/xid. Because it is small (not span too much on log line) and copy friendly.

Why I don't use auto increment key for primary key? The answer is simple, I don't want to write database specific SQL. SQLite has some different syntax from MySQL, and PostgreSQL and so on. Every logic I can move to application layer from database layer, I will.

In the past and present, I use google/uuid, specificially I use UUID v4. In the future I will look to use segmentio/ksuid and oklog/ulid (trial and error of course). Both are sortable, but google/uuid is not. The reason I'm afraid because the database is sensitive subject, and I need more testing and battle test proof to trust those libs.

I think about adding prefix to ID to identify which resource that ID represents.

• UUID, SERIAL OR IDENTITY COLUMNS FOR POSTGRESQL AUTO-GENERATED PRIMARY KEYS?
• Identity Crisis: Sequence v. UUID as Primary Key
• Generating good unique ids in Go
• How we used Go 1.18 when designing our Identifiers
• ULIDs and Primary Keys
• On IDs