From 4b1cde229d291257da7d9b7772ac38c8b928b161 Mon Sep 17 00:00:00 2001
From: Donne Martin <donne.martin@gmail.com>
Date: Wed, 1 Mar 2017 20:38:17 -0800
Subject: [PATCH] Add Write-behind (write-back) section

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

diff --git a/README.md b/README.md
index 4bfb8a3..3d267ea 100644
--- a/README.md
+++ b/README.md
@@ -1347,3 +1347,21 @@ Write-through is a slow overall operation due to the write operation, but subseq
 
 * 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.
+
+#### Write-behind (write-back)
+
+<p align="center">
+  <img src="http://i.imgur.com/rgSrvjG.png">
+  <br/>
+  <i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Source: Scalability, availability, stability, patterns</a></i>
+</p>
+
+In write-behind, tha application does the following:
+
+* Add/update entry in cache
+* Asynchronously write entry to the data store, improving write performance
+
+##### Disadvantage(s): write-behind
+
+* There could be data loss if the cache goes down prior to its contents hitting the data store.
+* It is more complex to implement write-behind than it is to implement cache-aside or write-through.