...which means you need a round-trip to the database before doing anything else. That's latency you can avoid with client-side predictable (or determined) UUID's.
Whether you should do anything else before the data has been persisted is a totally different discussion.
Unless you’re doing some wild async YOLO, you’re already waiting for the DB to send back success; adding a max of 8 bytes into that is highly likely to fit into the same TCP packet and thus add little to no overhead.
If you are doing async writes, as you alluded to, why bother with RDBMS in the first place? ACID is out the window.
- insert/then retrieve ID can easily result in duplicate records in some edge cases, and won’t necessarily be able to be easily fixed either. the inserted record doesn’t have a global ID until it’s inserted.
Can this generally be fixed using good transactions semantics? Yes usually. But it’s expensive. And in many cases you’ll have to default to failing writes instead of eventually consistent behavior.
- CRDT type behavior works better when things have a known valid unique ID from the get go. insert/update/ignore can happen quickly and easily without two way communication and in bulk, and edge cases have more easily modelable ‘eventual consistency’.
- generating unique IDs in the database forces serialization of certain processes in the database, which can cause scaling issues and high latency.
For instance, using the DB to create unique request IDs for web or API requests? Asking for problems.
Generating UUIDs for them at request time, and then putting those IDs where needed when later correlation/tracking is desirable? Much better.
Same can apply for other object ID creation, when there aren’t other natural keys that need to be checked first.
If you mean client like client, and not application server, don't do that (assuming you want to use uuidv7). Client generated IDs mean they can lie in the timestamp bits. Only use client generated ids as an idempotency key.
