Terracotta 10.7 | About Terracotta | What is Ehcache? | Topology Types
 
Topology Types
The following describes the basic types of caching topologies:
Standalone
The data set is held in the application node. Any other application nodes are independent with no communication between them. If a standalone topology is used where there are multiple application nodes running the same application, then their caches are completely independent.
Distributed / Clustered
The data is held in a remote server (or array of servers) with a subset of hot data held in each application node. This topology offers a selection of consistency options. A distributed topology is the recommended approach in a clustered or scaled-out application environment. It provides the best combination of performance, availability, and scalability.
Diagram illustrating two applications accessing a Terracotta Server. In the application, hot data is cached locally, hotter data in faster tiers. The data cached by one application instance is available to all cluster members. The full dataset is available to the cluster. One or more mirror servers may be deployed to provide High Availability. The ability to span data across multiple active servers for larger scale deployments is available commercially.
It is common for many production applications to be deployed in clusters of multiple instances for availability and scalability. However, without a distributed cache, application clusters exhibit a number of undesirable behaviors, such as:
*Cache Drift - If each application instance maintains its own cache, updates made to one cache will not appear in the other instances. A distributed cache ensures that all of the cache instances are kept in sync with each other.
*Database Bottlenecks - In a single-instance application, a cache effectively shields a database from the overhead of redundant queries. However, in a distributed application environment, each instance must load and keep its own cache fresh. The overhead of loading and refreshing multiple caches leads to database bottlenecks as more application instances are added. A distributed cache eliminates the per-instance overhead of loading and refreshing multiple caches from a database.