not sequential (not sortable & hard to use with databases)
too big
ULID (or UUIDv7)
pros
it's a standard
somewhat wide adoption
cons
too big and precise
custom made protocol
pros
can be exactly what we need
sequential
perfect size
cons
not a standard (no tooling)
After (not so) careful consideration, I decided to use a custom computable ID structure for this project: a 8 characters string ID where the first 6 characters stand for the timestamp, counting from 0 at 2024-01-01T00:00:00Z with seconds precision (you shall not have more than 1 thought per second, that's decided), and the last 2 are entropy (just to be safe).
Example: 07981T9G where the first 6 characters 07981T stand for the timestamp 2024-05-21T01:27:29.000Z and the last two 9G are random.
Caveats:
I might need to increase these 8 characters count, if some automation ever requires a high number of IDs per second;
This will stop working at 2092-12-23T05:45:35Z, as the timestamp reaches its limit of "ZZZZZZ". I'm free to be mad at myself then (if I still live).
options:
After (not so) careful consideration, I decided to use a custom computable ID structure for this project: a 8 characters string ID where the first 6 characters stand for the timestamp, counting from 0 at
2024-01-01T00:00:00Zwith seconds precision (you shall not have more than 1 thought per second, that's decided), and the last 2 are entropy (just to be safe).Example:
07981T9Gwhere the first 6 characters07981Tstand for the timestamp2024-05-21T01:27:29.000Zand the last two9Gare random.Caveats:
2092-12-23T05:45:35Z, as the timestamp reaches its limit of "ZZZZZZ". I'm free to be mad at myself then (if I still live).