[id='scattered-caches_{context}']
= Scattered caches

Scattered caches are very similar to distributed caches as they allow linear scaling of the cluster.
Scattered caches allow single node failure by maintaining two copies of the data (`numOwners=2`).
Unlike distributed caches, the location of data is not fixed; while we use the same Consistent Hash algorithm to locate the primary owner, the backup copy is stored on the node that wrote the data last time.
When the write originates on the primary owner, backup copy is stored on any other node (the exact location of this copy is not important).

This has the advantage of single Remote Procedure Call (RPC) for any write (distributed caches require one or two RPCs), but reads have to always target the primary owner.
That results in faster writes but possibly slower reads, and therefore this mode is more suitable for write-intensive applications.

Storing multiple backup copies also results in slightly higher memory consumption.
In order to remove out-of-date backup copies, invalidation messages are broadcast in the cluster, which generates some overhead.
This lowers the performance of scattered caches in clusters with a large number of nodes.

When a node crashes, the primary copy may be lost.
Therefore, the cluster has to reconcile the backups and find out the last written backup copy.
This process results in more network traffic during state transfer.

Since the writer of data is also a backup, even if we specify machine/rack/site IDs on the transport level the cluster cannot be resilient to more than one failure on the same machine/rack/site.

[NOTE]
====
You cannot use scattered caches with transactions or asynchronous replication.
====

The cache is configured in a similar way as the other cache modes, here is an example of declarative configuration:

[source,xml,options="nowrap",subs=attributes+]
----
include::xml/scattered_cache.xml[]
----

[source,java]
----
include::code_examples/ScatteredCache.java[]
----

Scattered mode is not exposed in the server configuration as the server is usually accessed through the Hot Rod
protocol. The protocol automatically selects primary owner for the writes and therefore the write (in distributed
mode with two owner) requires single RPC inside the cluster, too. Therefore, scattered cache would not bring
the performance benefit.
