Merge branch 'active-active' into 'master'

Some notes.

See merge request !44

1 files changed, 2 insertions, 1 deletions

diff --git a/README.md b/README.md
index 420392aef..4457c544d 100644
--- a/README.md
+++ b/README.md
@@ -55,7 +55,7 @@ Gitaly will make our situation better in a few steps:
 1. One central place to monitor operations
 1. Performance improvements doing less and caching more
 1. Move the git operations from the app to the file/git server with git rpc (routing git access over JSON HTTP calls)
-1. Use Git ketch to allow active-active (push to a local server), and distributed read operations (read from a secondary).
+1. Use Git ketch to allow active-active (push to a local server), and distributed read operations (read from a secondary). This is far in the future, we might also use a distributed key value store instead. See the [active-active issue](https://gitlab.com/gitlab-org/gitlab-ee/issues/1381). Until we are active active we can just use persistent storage on the cloud to shard, this eliminates the need for redundancy.
 
 ## Decisions
 
@@ -87,6 +87,7 @@ All design decision should be added here.
 1. Use gitaly-client or HTTP/websocket clients? gitlab-shell copies the SSH stream, both ways, to gitaly over a websocket, workhorse just forwards the request to Gitaly, let’s use HTTP. https://gitlab.com/gitlab-org/gitaly/issues/5#note_20294280
 1. We will use [E3 from BitBucket to measure performance closely in isolation](https://gitlab.com/gitlab-org/gitaly/issues/34).
 1. Use environment variables for setting configurations (see #20).
+1. GitLab already has [logic so that the application servers know which file/git server contains what repository](https://docs.gitlab.com/ee/administration/repository_storages.html), this eliminates the need for a router.
 
 ## Iterate