|
| 1 | +--- |
| 2 | +title: Caching in a cloud-native application |
| 3 | +description: Learn about caching strategies in a cloud-native application. |
| 4 | +author: robvet |
| 5 | +ms.date: 01/22/2020 |
| 6 | +--- |
| 7 | +# Caching in a cloud-native app |
| 8 | + |
| 9 | +[!INCLUDE [book-preview](../../../includes/book-preview.md)] |
| 10 | + |
| 11 | +The benefits of caching are well understood. The technique works by temporarily copying frequently accessed data from a backend data store to *fast storage* that's located closer to the application. Caching is often implemented where... |
| 12 | + |
| 13 | +- Data remains relatively static. |
| 14 | +- Data access is slow, especially compared to the speed of the cache. |
| 15 | +- Data is subject to high levels of contention. |
| 16 | + |
| 17 | +## Why? |
| 18 | + |
| 19 | +As discussed in the [Microsoft caching guidance](https://docs.microsoft.com/azure/architecture/best-practices/caching), caching can increase performance, scalability, and availability for individual microservices and the system as a whole. It reduces the latency and contention of handling large volumes of concurrent requests to a data store. As data volume and the number of users increase, the greater the benefits of caching become. |
| 20 | + |
| 21 | +Caching is most effective when a client repeatedly reads data that is immutable or that changes infrequently. Examples include reference information such as product and pricing information, or shared static resources that are costly to construct. |
| 22 | + |
| 23 | +While microservices should be stateless, a distributed cache can support concurrent access to session state data when absolutely required. |
| 24 | + |
| 25 | +Also consider caching to avoid repetitive computations. If an operation transforms data or performs a complicated calculation, cache the result for subsequent requests. |
| 26 | + |
| 27 | +## Caching architecture |
| 28 | + |
| 29 | +Cloud native applications typically implement a distributed caching architecture. The cache is hosted as a cloud-based [backing service](./definition.md#backing-services), separate from the microservices. Figure 5-20 shows the architecture. |
| 30 | + |
| 31 | + |
| 32 | + |
| 33 | +**Figure 5-19**: Caching in a cloud native app |
| 34 | + |
| 35 | +In the previous figure, note how the cache is independent of and shared by the microservices. In this scenario, the cache is invoked by the [API Gateway](./front-end-communication.md). As discussed in chapter 4, the gateway serves as a front end for all incoming requests. The distributed cache increases system responsiveness by returning cached data whenever possible. Additionally, separating the cache from the services allows the cache to scale up or out independently to meet increased traffic demands. |
| 36 | + |
| 37 | +The figure presents a common caching pattern known as the [cache-aside pattern](https://docs.microsoft.com/azure/architecture/patterns/cache-aside). For an incoming request, you first query the cache (step \#1) for a response. If found, the data is returned immediately. If the data doesn't exist in the cache (known as a [cache miss](https://www.techopedia.com/definition/6308/cache-miss)), it's retrieved from a local database in a downstream service (step \#2). It's then written to the cache for future requests (step \#3), and returned to the caller. Care must be taken to periodically evict cached data so that the system remains timely and consistent. |
| 38 | + |
| 39 | +As a shared cache grows, it might prove beneficial to partition its data across multiple nodes. Doing so can help minimize contention and improve scalability. Many Caching services support the ability to dynamically add and remove nodes and rebalance data across partitions. This approach typically involves clustering. Clustering exposes a collection of federated nodes as a seamless, single cache. Internally, however, the data is dispersed across the nodes following a predefined distribution strategy that balances the load evenly. |
| 40 | + |
| 41 | +## Azure Cache for Redis |
| 42 | + |
| 43 | +[Azure Cache for Redis](https://azure.microsoft.com/services/cache/) is a secure data caching and messaging broker service, fully managed by Microsoft. Consumed as a Platform as a Service (PaaS) offering, it provides high throughput and low-latency access to data. The service is accessible to any application within or outside of Azure. |
| 44 | + |
| 45 | +The Azure Cache for Redis service manages access to open-source Redis servers hosted across Azure data centers. The service acts as a facade providing management, access control, and security. The service natively supports a rich set of data structures, including strings, hashes, lists, and sets. If your application already uses Redis, it will work as-is with Azure Cache for Redis. |
| 46 | + |
| 47 | +Azure Cache for Redis is more than a simple cache server. It can support a number of scenarios to enhance a microservices architecture: |
| 48 | + |
| 49 | +- An in-memory data store |
| 50 | +- A distributed non-relational database |
| 51 | +- A message broker |
| 52 | +- A configuration or discovery server |
| 53 | + |
| 54 | +For advanced scenarios, a copy of the cached data can be [persisted to disk](https://docs.microsoft.com/azure/azure-cache-for-redis/cache-how-to-premium-persistence). If a catastrophic event disables both the primary and replica caches, the cache is reconstructed from the most recent snapshot. |
| 55 | + |
| 56 | +Azure Redis Cache is available across a number of predefined configurations and pricing tiers. The [Premium tier](https://docs.microsoft.com/azure/azure-cache-for-redis/cache-premium-tier-intro) features many enterprise-level features such as clustering, data persistence, geo-replication, and virtual-network isolation. |
| 57 | + |
| 58 | +>[!div class="step-by-step"] |
| 59 | +>[Previous](relational-vs-nosql-data.md) |
| 60 | +>[Next](elastic-search-in-azure.md) |
0 commit comments