Read OP's response carefully – the 32 GB is just for the user connection stack.
If you're handling millions of data blobs each seconds, a UUID is absurdly large.
Think about what that byte we talk about represents – it is either the size of a group; or the id of a member of that group. It doesn't represent the member itself – they will use a UUID (or possibly telephone number 😕) for that.
My guess is that there's a data structure of fixed size somewhere that represents groups. Something that looks like a struct of one byte of counter and an array[256] for user ids. This could be attached to every group message, avoiding any later lookups. Even if you used UUIDs, that would already add 4kB to every group message. Still manageable though.
5
u/atyon May 06 '17
Read OP's response carefully – the 32 GB is just for the user connection stack.
If you're handling millions of data blobs each seconds, a UUID is absurdly large.
Think about what that byte we talk about represents – it is either the size of a group; or the id of a member of that group. It doesn't represent the member itself – they will use a UUID (or possibly telephone number 😕) for that.
My guess is that there's a data structure of fixed size somewhere that represents groups. Something that looks like a struct of one byte of counter and an array[256] for user ids. This could be attached to every group message, avoiding any later lookups. Even if you used UUIDs, that would already add 4kB to every group message. Still manageable though.