README.md in routemaster-drain-2.5.2 vs README.md in routemaster-drain-2.5.3

@@ -34,11 +34,11 @@
 
 Add this line to your application's Gemfile:
 
     gem 'routemaster-drain'
 
-**Configuration**
+### Configuration
 
 This gem is configured through the environment, making 12factor compliance
 easier.
 
 Required:
@@ -64,10 +64,21 @@
 - `ROUTEMASTER_QUEUE_NAME`: if using the cache, on which Resque queue the cache
   population jobs should be enqueued.
 - `ROUTEMASTER_CACHE_TIMEOUT`: if using the cache, how long before Faraday will timeout fetching the resource. Defaults to 1 second.
 - `ROUTEMASTER_CACHE_VERIFY_SSL`: if using the cache, whether to verify SSL when fetching the resource. Defaults to false.
 
+Alternatively, it's possible to configure the gem to use pre-initialized Redis clients for the Cache Redis, the Drain Redis, or both.
+
+The clients are expected to be instances of `Redis::Distributed`. When configured, the pre-built clients take precendence and the gem won't try to estabilish its own private connection to the Redis instances supplied in the ENV variables. This is helpful if you want to re-use connections in order to reduce the number of connected clients to your Redis servers.
+
+```ruby
+Routemaster::RedisBroker.instance.inject(
+  drain_redis: a_redis_object,
+  cache_redis: another_redis_object
+)
+```
+
 ## Illustrated use cases
 
 
 ### Simply receive events from Routemaster
 
@@ -175,22 +186,22 @@
 cache as events are received.
 
 For this purpose, use `Routemaster::Drain::Caching`:
 
 ```ruby
-require 'routemaster/drain/machine'
+require 'routemaster/drain/caching'
 $app = Routemaster::Drain::Caching.new
 ```
 
 And mount it as usual:
 
 ```ruby
 # in config.ru
 map('/events') { run $app }
 ```
 
-You can still attach a listenenr if you want the incoming events. Typically,
+You can still attach a listener if you want the incoming events. Typically,
 what you'll want is the cache:
 
 ```ruby
 require 'routemaster/cache'
 $cache = Routemaster::Cache.new
@@ -204,21 +215,38 @@
 whenever the drain gets notified about a change on that widget.
 
 Note that `Cache#fget` is a future, so you can efficiently query many resources
 and have any `HTTP GET` requests (and cache queries) happen in parallel.
 
+Resources are fetched through jobs. By default it uses Resque but can be changed
+to use Sidekiq.
+
+```
+ROUTEMASTER_QUEUE_ADAPTER=sidekiq
+```
+
+Finally do not forget the corresponding backend:
+```
+# config/initializers/...
+
+require 'routemaster/jobs/backends/sidekiq'
+# or
+require 'routemaster/jobs/backends/resque'
+```
+
+
 See
 [rubydoc](http://rubydoc.info/github/deliveroo/routemaster-drain/Routemaster/Cache)
 for more details on `Cache`.
 
 ### Expire Cache data for all notified resources
 
-You may wish to maintain a coherent cache but don't need the cache to be warmed
+You may wish to maintain a coherent cache, but don't need the cache to be warmed
 before you process incoming events. In that case, use the cache as detailed above
-but swap the `Caching` drain out for `CachingBusting`
+but swap the `Caching` drain out for `CacheBusting`
 
 ```ruby
-require 'routemaster/drain/machine'
+require 'routemaster/drain/caching_busting'
 $app = Routemaster::Drain::CachingBusting.new
 ```
 
 ## HTTP Client
 The Drain is using a Faraday http client for communication between services. The client