[caust1c]

> it prevents entire classes of bugs where IDs get mixed up across services.

~Does this really happen for people? I haven't ever seen this class of bug, and shudder to think of how it happens in code. Sure support tickets are nicer with the prefix, but how would a bug manifest in the code itself?~

Edit: of course it can happen with `new.id = old.id` where new and old are different types, now that I think about it after coffee. However, I'd be hesitant to claim that this prevents those bugs, instead I'd argue that it simply makes them easier to identify.

Also, KSUID has been around since before UUIDv7 and seems to meet all of the author's same requirements and has many client libraries already. Guess people doing research on it still aren't able to find it, or just want to do their own anyway which is cool too.

[IanCal]

A few things here, one is that getting them mixed up isn't the same as them ending up in the wrong place. Looking fruitlessly for a missing user with id 9287dfn9384f that has some support ticket only to find out later that this was their order ID and the wrong thing was put in a form (particularly if you ask users for something, I see 4 different IDs floating around, which is my customer/user/product/order/shipping id?). If the user id is "order_1239123" I know to go and look at the orders table, not "dance around all tables trying to find what on earth the id could relate to".

However there are two other ways this happens which come to mind:

1. HTTP API calls. There's a whole untyped layer going on here. You could have a PUT to set some content, and create a new entry if one doesn't exist - there's a place for a call to go to the wrong place but succeed. If two entities have the same structure but are different things this can be harder to spot.

2. Manual entry. This is the bigger one. Vast amounts of workflows have somewhere that a human does a thing, and that will go wrong at times. An excel file uploaded to the wrong place, the wrong header, the wrong bit typed on a form.

A counting up of numbers is a simple ID but awful for both of these, because now you have overlapping IDs across systems. Having larger random IDs takes you out of this risky area because at some point the chance of a collision is so low as to be not worth considering, however even small IDs with a prefix like "customer_001" and "order_001" quickly removes a source of problems.

I'm not saying any of this is the only solution, or that there aren't better ones, but I can see places where this kind of thing can easily happen in the real world and "prefix the ids with a type" is a very small and simple change that can help.

I would also note that this then becomes a front facing thing that ties you into something as well though, and not all types are as nice to make public.