Querki should be able to failover to a new region if necessary

(User Story, Investigate , Priority: High, Test Status: No automated tests yet , Reported By Justin du Coeur, )
Summary: Inspired by The Great AWS Outage of September 20th (2015): we should be able to cope if us-east-1 goes down.
On the morning of 9/20/15, a metadata service inside Dynamo in us-east-1 went down, and took a quarter of the Internet with it. While I don't expect that exact problem to repeat, it drives home that redundancy is important.
Once Akka Persistence is up and running as our new database, we should probably keep a cold backup of the DB living in another region (eg, us-west-1), so that if something goes wrong in us-east-1, we can do a cold switch to that. There would be downtime, but possibly not very much.
Later: In the long run, the more ambitious and technically correct approach would be cloud-enable Querki, spanning a number of geographic regions. The "main" copy of any given Space would live in the region nearest its Owner, for better average latency, but each Space would be replicated at least once, ideally twice, in a different geographic region. If, for some reason, the main region wasn't available, the system would automatically switch traffic to a backup.
This is quite a bit more difficult, since it implies setting up the Akka cluster over the WAN. Latency would be a serious issue to wrestle with, as would security (we'd basically need SSL tunnels connecting all of the clusters, or something like that), but in principle there isn't anything hard about it -- it's just a great deal of work and a huge amount of stress-testing. (If we're lucky, there might be proper Akka-WAN libraries for this by then.)
Done right, it would make Querki extremely resilient to any localized outages.