Therein lies the problem

By insulating the database from the read load, a problem is introduced in the form of a cache consistency issue. How does the local data cache deal with data changing underneath it within the primary database? The answer is rather disappointing—it can't! The manifestation of issues will largely depend on the data needs of the application and how frequently the data changes, but typically, caching systems will operate in one of the following two modes to combat the problem:

• Time-bound cache: This holds entries for a defined period (time-to-live, popularly abbreviated as TTL)

• Write-through cache: This holds entries until they are invalidated by subsequent updates

Time-bound caches almost always have consistency issues, but at least the amount of time that the issue would be present is limited to the expiry time of each entry. However, we must consider the application's access to this data, because if the frequency of accessing a particular entry is less than its cache expiry time, the cache provides no real benefit.

Write-through caches are consistent in isolation and can be configured to offer strict consistency, but if multiple write-through caches exist within the overall architecture, then there will be consistency issues between them. We can avoid this by having an intelligent cache that features a communication mechanism between the nodes that can propagate entry invalidations to the other nodes.

In practice, an ideal cache will feature a combination of both the features so that the entries will be held for a known maximum time, but will also pass around invalidations as changes are made.

So, the evolved architecture will look like the following figure:

So far, we had a look at the general issues in scaling a data layer and introduced strategies to help combat the trade-offs that we will encounter along the way. However, the real world isn't this simple. There are various cache servers and in-memory database products in this area (such as memcached or Ehcache). However, most of these are stand-alone single instances, perhaps with some degree of distribution bolted on or provided by other supporting technologies. This tends to bring about the same issues that we experienced with the primary database in that we may encounter resource saturation or capacity issues if the product is a single instance or the distribution doesn't provide consistency control, perhaps inconsistent data, which might harm our application.