diff --git a/Design:-Runtime-extension-points.md b/Design:-Runtime-extension-points.md
index 66171be..30f1b91 100644
--- a/Design:-Runtime-extension-points.md
+++ b/Design:-Runtime-extension-points.md
@@ -16,7 +16,7 @@ This could be done in the existing storage-plugin layer.
 
 ### Running a flow across multiple instances
 
-This is where a flow is distributed across multiple runtimes. Two connected nodes may not be running on the same instance.
+This is where a flow is distributed across multiple runtimes. Two connected nodes may not be running in the same instance.
 
 The requirements are:
 
@@ -27,4 +27,5 @@ The requirements are:
 
  - Storage layer - how/where things get stored - [already done](http://nodered.org/docs/api/storage/index.html).
  - Message routing - how a message gets routed. Default implementation does the in-memory direct access to a node's `.receive` function. Alternative implementations could serialise the message to JSON and send over the network
- - Flow handling - sits in the load/save path for flows. Need to refine how much is exposed to the API and where exactly it sits in the deploy process.
\ No newline at end of file
+ - Flow handling - sits in the load/save path for flows. Need to refine how much is exposed to the API and where exactly it sits in the deploy process.
+ - Context backing - we intend to make [context more widely used](https://github.com/node-red/node-red/issues/567). As soon as a flow can run in multiple instances, the shared context needs to be truly shared. This extension point would allow a backing store to be plugged in - for example Redis. Even in the single-instance case, this would allow context to be persisted.
\ No newline at end of file