I remember when Twitter had rolled over their tweet ID's because they were using an int type that was too short. Should have gone with variable length strings to avoid that problem.
It isn't a uint32, it is an int32.
Using strings avoids one problem but introduce a bunch of others (e.g. a string is harder to verify, therefore less secure, and therefore needs to be handled with the kiddie gloves). Checking that every character is between 0-9 and dropping all other characters is easy, cheap, and effective. Then just check it is between uint64.Min and uint64.Max, and you're done.
uint32 gives them twice as much capacity (which isn't enough at this stage), they'll likely want to go with a uint64.
[0] https://en.wikipedia.org/wiki/Globally_unique_identifier#Alg...
ObjectId is a 12-byte BSON type, constructed using:
a 4-byte value representing the seconds since the Unix epoch,
a 3-byte machine identifier,
a 2-byte process id, and
a 3-byte counter, starting with a random value.
12 bytes is enough to just store a random value, with low chance of collisions until you've got around 100 trillion items. It confuses me why anyone would want to waste bytes of an ID on low entropy values like machine and process ID.
Or any combination of high res time plus random works nicely.
OTOH, Mongo's not exactly been a bastion of engineering excellence.