caching docs: Tweak a few things.

Some claims seemed a little exaggerated or overly
precise.

docs/subsystems/caching.md

@@ -10,9 +10,9 @@ caching).
 
 On the backend, Zulip uses `memcached`, a popular key-value store, for
 caching. Our `memcached` caching helps let us optimize Zulip's
-performance and scalability, since most requests don't need to talk to
-the database (which, even for a trivial query with everything on the
-same machine, usually takes 3-10x as long as a memcached fetch).
+performance and scalability, since we often avoid overhead related
+to database requests. With Django a typical trivial query can
+often take 3-10x as long as a memcached fetch.
 
 We use Django's built-in caching integration to manage talking to
 memcached, and then a small application-layer library
@@ -32,10 +32,10 @@ amount of Zulip's core caching code correctly, then the code most developers
 naturally write will both benefit from caching and not create any cache
 consistency problems.
 
-The overall result of this design is that in the vast majority of
+The overall result of this design is that for many places in the
 Zulip's Django codebase, all one needs to do is call the standard
-accessor functions for data (like `get_user` or `get_stream` to fetch
-user and stream objects, or for view code, functions like
+accessor functions for data (like `get_user` to fetch
+user objects, or, for view code, functions like
 `access_stream_by_id`, which checks permissions), and everything will
 work great. The data fetches automatically benefit from `memcached`
 caching, since those accessor methods have already been written to
@@ -96,7 +96,7 @@ This decorator implements a pretty classic caching paradigm:
   `KEY_PREFIX` is rotated every time we deploy to production; see
   below for details.
 
-We use this decorator in more than 30 places in Zulip, and it saves a
+We use this decorator in about 30 places in Zulip, and it saves a
 huge amount of otherwise very self-similar caching code.
 
 ### Cautions