Caching information is not a new concept and is available on many other platforms, for example, MemCache is a popular open source framework for providing a cache facility. The main motivation for considering caching is performance.
As mentioned earlier, state is not retained between requests. You may find that common information needs to be constantly queried or calculated. If the chances of such information changing are low, caches can be considered to gain a performance benefit. The cost, in terms of Apex execution (CPU Governor) and/or database queries (SOQL and Row Governors) has to be less than retrieving it from the cache.
Platform Cache allows you to retain state beyond the scope of the request, up to 48 hours for the org-level cache and 8 hours for the session-level cache. A session-level cache only applies to the interactive context, and it is not available in async Apex. Your code can clear cached information ahead of the expiry times if users change information that the cached information is dependent on. Apex provides APIs under the Cache namespace for storing (putting), retrieving (getting), and clearing information from either of the caches. There is also a $Cache variable to retrieve information from the session cache within a Visualforce page. Unfortunately, there is currently no $Cache access for Lightning Component markup at the time of writing. As such, Apex Controllers must be used.
Think carefully about the lifespan of what you put in the cache—once it goes in, the whole point is that it stays in the cache as long as possible and thus the performance benefit is obtained more often than not. If you are constantly changing it or clearing the cache out, the benefit will be reduced. Equally, information can become stale and out of date if you do not correctly consider places in your application where you need to invalidate (clear) the cache. This consideration can get quite complex depending on what you are storing in the cache, for example, if the information is a result of a calculation involving a number of records and objects.
The amount of cache available depends on the customer org type. Enterprise edition orgs currently get 10 MB by default, whereas Unlimited and Performance edition orgs get 30 MB. You cannot package storage, though more can be purchased by customers. To test the benefits of Platform Cache in a Developer edition org, you can request a trial allocation from Salesforce from the Platform Cache page, under Setup. Salesforce uses a Least Recently Used (LRU) algorithm to manage cache items.
The amount of cache available can be partitioned (split), much like storage partitions on a hard disk. This allows the administrator to guarantee a portion of the allocation is used for a specific application only, and, if needed, adjust it depending on performance needs. As the package developer, you can reference local partitions (created by the administrator) by name dynamically. You can also package a partition name for use exclusively by your application and reference it in your code. This ensures any allocation assigned after the installation of your package by the administrator to your partition is guaranteed to be used by your application. If your code was to share a partition, you may not want other applications constantly pushing out your cached entries, for example.
The Salesforce Apex Developers Guide contains a Platform Cache subsection that goes into further detail on the topics I have covered in this section, including further best practices and usage guidelines. You can refer to this guide at https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_cache_namespace_overview.htm.