What are best practices with custom user data considering the 16KB limit?

So according to the info in the link below there is a 16KB limit on custom user data:

Right now I have separate collections for pending data updates, password info, security questions and answers, closed accounts, and phone numbers.

I would like to fold this all into the user’s document to reduce the number of collections and the need to fetch data from them.

But because there is a 16KB limit this poses problems. For example (in theory at least) a user could have a list of previous passwords or phone numbers that is so long that it exceeds the 16KB limit.

I was wondering if making a field unreadable using roles and permissions prevents that field from being included with custom user data that is returned to the user when they login on the client using the web sdk. Correct me if I am wrong but my assumption is that the 16KB limit comes into play in that there is only a certain amount of data that can be sent to client and included with user object. So does all the custom user data get sent to the client when they login even if some fields are unreadable?

Any guidance is appreciated.

So at a glance it seems making a field unreadable will not prevent it from being included in the custom user data that is included with the user object when the user logs in using the web sdk. For example I made the field customDataId unreadable in Atlas:

image

But the field is included with the custom user data. Is there a way to limit what fields get included so too much data isn’t provided? I guess I could just continue using separate collections even though it makes things less streamlined.

image