From 1945024e5bccc581d39143b1400051f5e0ae204f Mon Sep 17 00:00:00 2001
From: Donne Martin <donne.martin@gmail.com>
Date: Wed, 1 Mar 2017 20:37:12 -0800
Subject: [PATCH] Add Caching at the database query level vs obj level sections

---
 README.md | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/README.md b/README.md
index b4065281..6fc812ad 100644
--- a/README.md
+++ b/README.md
@@ -1252,3 +1252,24 @@ There are multiple levels you can cache that fall into two general categories: *
 * Fully-rendered HTML
 
 Generaly, you should try to avoid file-based caching, as it makes cloning and auto-scaling more difficult.
+
+### Caching at the database query level
+
+Whenever you query the database, hash the query as a key and store the result to the cache.  This approach suffers from expiration issues:
+
+* Hard to delete a cached result with complex queries
+* If one piece of data changes such as a table cell, you need to delete all cached queries that might include the changed cell
+
+### Caching at the object level
+
+See your data as an object, similar to what you do with your application code.  Have your application assemble the dataset from the database into a class instance or a data structure(s):
+
+* Remove the object from cache if its underlying data has changed
+* Allows for asynchronous processing: workers assemble objects by consuming the latest cached object
+
+Suggestions of what to cache:
+
+* User sessions
+* Fully rendered web pages
+* Activity streams
+* User graph data