The default cache mode is partitioned mode. This mode is designed for achieving high scalability. In partitioned mode, the cache data is divided equally into a number of partitions, defined in the configuration, and the partitions are distributed equally between participating nodes. By default, the partition count is 2: one primary and one backup. You can modify the backup copy count. 

The following diagram describes the concept. We have three participating JVMs and one cache. The cache has three keys, Key 1, Key 2, and Key 3, and the cache configuration is set with a default backup=1. The distributed cache mode keeps a primary copy of Key 1 in JVM 1 and a backup of of Key 1 in JVM 2. Similarly for Key 2 and Key 3; it keeps a backup and a primary copy. If we add another key, Key 4, it will be distributed within the 3 JVMs. It could keep the primary copy of Key 4 in any of the available JVMs, say in JVM 2, then the backup copy of Key 4 will be kept in either JVM 1 or JVM 3:

So, if we add more JVMs, then we can store more data. The distribution of data is transparent to the nodes. If a new node is added or a node goes down, the cluster redistributes the data. 

The drawback of this approach is that if you connect to a node where the data (Key) is not present, then the cluster has to make two hops to fetch you the key. 

Apache Ignite recommends that you use partitioned mode when you are working with a huge dataset and updating the data very frequently, so that the cluster can distribute the data and offer you high scalability. When you update a value, it doesn't have to propagate the change to all the nodes of the cluster; it just needs to update the backup copies, hence the write performance is better in this mode.