Add Write-through section

README.md

@@ -1312,3 +1312,38 @@ Subsequent reads of data added to cache are fast.  Cache-aside is also referred
 * Each cache miss results in three trips, which can cause a noticeable delay.
 * Data can become stale if it is updated in the database.  This issue is mitigated by setting a time-to-live (TTL) which forces an update of the cache entry, or by using write-through.
 * When a node fails, it is replaced by a new, empty node, increasing latency.
+
+#### Write-through
+
+<p align="center">
+  <img src="http://i.imgur.com/0vBc0hN.png">
+  <br/>
+  <i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Source: Scalability, availability, stability, patterns</a></i>
+</p>
+
+The application uses the cache as the main data store, reading and writing data to it, while the cache is responsible for reading and writing to the database:
+
+* Application adds/updates entry in cache
+* Cache synchronously writes entry to data store
+* Return
+
+Application code:
+
+```
+set_user(12345, {"foo":"bar"})
+```
+
+Cache code:
+
+```
+def set_user(user_id, values):
+    user = db.query("UPDATE Users WHERE id = {0}", user_id, values)
+    cache.set(user_id, user)
+```
+
+Write-through is a slow overall operation due to the write operation, but subsequent reads of just written data are fast.  Users are generally more tolerant of latency when updating data than reading data.  Data in the cache is not stale.
+
+##### Disadvantage(s): write through
+
+* When a new node is created due to failure or scaling, the new node will not cache entries until the entry is updated in the database.  Cache-aside in conjunction with write through can mitigate this issue.
+* Most data written might never read, which can be minimized with a TTL.