The most common operation on the catalogue data is read (or browse). A typical catalogue browse operation iterates over a large amount of product data, filters it, personalises it, and then presents the selected data to the users. Key-based and query-based access is a common form of operation. Caching is a critical requirement for catalogue access. If not cached, operations against such an aggregate catalogue require the operations to be broken up into operations on the underlying sources -- invoke the underlying operations, collect responses, and aggregate the results into cohesive responses. Accessing the large sets of backend data for every catalogue operation can be prohibitively expensive, and can significantly impact the response time and throughput of the application. Caching the backend product data closer to the catalogue application can significantly improve the performance and the scalability of the application. Similarly, aggregated flight schedules are another example of reference data.

Referenced data is refreshed periodically, usually at pre-configured intervals, from its sources, or refreshed when the authoritative data sources change. Access to reference data, though shared, is mostly read. Local updates are often performed for tagging (to better organise the data). To support a large scale, reference data can be replicated in multiple caches on different machines in a cluster. As shown below, in a social networking scenario, details of the friends list, usernames associated with a particular ID/user login, etc would be such reference data that is easy to cache and provides high scalability.

Activity-oriented data
Activity-oriented data is generated by the currently executing activity as part of a business transaction. The data originates as part of the business transaction and, eventually, at the close of the business transaction, it is retired to the backend data source as historical (or log) information. Consider the shopping cart data in an online buying application. There is one shopping cart, which is exclusive for each online buying session. During the buying session, the shopping cart is cached and updated with the products purchased. The shopping cart is visible and accessible only to the buying transaction. Upon checkout, once the payment is applied, the shopping cart is retired (from the cache) to a backend application for further processing. Once the business transaction is processed by the backend application, the shopping cart information is logged for auditing (and historical) purposes.

While the buying session is active, the shopping cart is accessed both for read and write operations; however, it is not shared. This exclusive access of the activity data makes it suitable for distributed caching. To support large scalability of the buying applications, the shopping carts can be distributed across the cluster of caches. Since these carts are not shared, the set of shopping carts can be partitioned across the distributed cache. By dynamically configuring the distributed cache, the degree of the scale can be controlled.

Resource-oriented data
Both reference (shared read) and activity (exclusive write) data are ideal for caching. However, not all application data falls into these two categories. There is data that is shared, concurrently read and written into, and accessed by a large number of transactions. For example, consider an inventory management application. The inventory of an item has the description of the item and the current quantity. The quantity information is authoritative, volatile, and concurrently accessed by a large number of users for read/write operations. Such data is known as the resource data; the business logic (e.g., the order application logic) runs close to the resource data (e.g., quantity data). The resource data is typically stored in the backend data stores. However, for performance reasons it is cached in the application tier. While caching the quantity data in memory on a single machine can provide performance improvements, a single cache cannot provide availability or scale when the order volume is high. For this purpose, the quantity data can be replicated in multiple caches across the distributed cache. However, since quantity is shared and concurrently updated, the consistency of the quantity values need to be maintained across the distributed cache. Maintaining consistency in distributed caches requires data replication, transactions, data change notifications, and invalidations. However, support for high performance and scale requires relaxed notions of consistency and transaction. For example, the seat inventory in a flight booking application is an example of resource-oriented data.

The following table illustrates some real-world application domains and scenarios that use distributed caching for application performance and scale. In this table, the application space is divided into Web and LOB (line of business) applications. Most Web applications use caches for reference and activity data, and occasional resource data (e.g., inventory). Enterprise Lines of Business are also increasingly leveraging distributed caches for reference and activity data scale up, to reduce the load on the backend authoritative database system.