Hehe, this was kind of my thesis back 2015; non public unfortunately, but I think the following is save to share: So basically they had the need to persist huge collections of objects that would not fit into a single servers RAM. As for persistence, a key value NoSQL db was chosen (which is a natural fit for a world where everything has a unique identity - I also have some dislike for ORMs because of that, because I saw how beautiful it could synergize, and how ugly some mechanism are that hibernate, EC Framework etc. have to implement in order to brigde the gap between objects and relational dbs).

The core pattern was that the Proxy, which was under Nil and above all other Objects regarding inheritance I think.

It re-implemented `doesNotUnterstand:` by: 1) First loading the actual object from the persistent storage and 2) sending the not understood message to the actual loaded object (which might be able to answer the message instead of calling `doesNotUnderstand:` for every message, like Proxy did.

There where if course optimisations and so on, but that was the gist of it.

What I really like about this system was that it was completely transparent to the sender of the message whether they were talking to a proxy, or the already-loaded object, all while being robust, easy to maintain and so ob. Dealing with collections was tricky though (how much to load at once? what about searching for a particular object?...), and would have been aswell for deeply nested object (which they successfully avoided though because as a SaaS-company, they could model the data exactly to their needs).