Master-Local -- the most common topology in IMDG

IMDG (In-Memory-Data-Grid) functions like an in-memory database to the front end users. In order to be scalable, IMDG has to provide partitioned topology besides the replicated one.

If we bundle an application locally with a data partition together and the application only processes its local data, we form what the GigaSpaces calls a PU(Processing Unit).
Because PU doesn't need to communicate with others, we can achieve linear scalability by deploying multiple PUs.

However such a tightly couple application rarely exists practically.
On one hand IMDG basically partitions data evenly without caring about too much of your application. After all IMDG, as the delegate of a system of record (the database), should be able to server all applications.
On the other hand your application should implement your specific business logic and you may have different applications for different business requirements.

So your universal data and your specific business requirements are just conflicting with each other.
To solve this dilemma, a Master-Local topology is often employed where the master cache (or Data-only Processing Unit or EDG in GigaSpaces) itself can be either replicated, partitioned or both; the local cache (or embedded space in GigaSpaces), caches data from, and synchronizes any update with, the master on demand. The communication between local and master is usually a single network hop and extreme low latency can be achieved using switches.
Here is a diagram from GigaSpaces where the master is replicated:

If your local cache is read-only, the performance is the best.
Oracle Coherent also calls the above topology as Near Cache.

Going back to GigaSpaces' "XAP Order Management Tutorial" in its XAP 7.0.0 "Quick Start Guide" section. As its comment mentions, the AccountData comes from IMDG which is simulated by AccountDataLoader in the example. In practice it should come from an EDG which connects to the local embedded space in the order runtime processing unit.