docs: Fix small issues in architecture overview.

Typos and removing now-inaccurate discussion of the incoming email
integration as a use case for redis.

docs/overview/architecture-overview.md

@@ -41,7 +41,7 @@ Usage assumptions and concepts
 
 Zulip is a real-time team chat application meant to provide a great
 experience for a wide range of organizations, from companies to
-volunteer projects groups of friends, ranging in size from a small
+volunteer projects to groups of friends, ranging in size from a small
 team to 10,000s of users.  It has [hundreds of
 features](https://zulipchat.com/features) both larger and small, and
 supports dedicated apps for iOS, Android, Linux, Windows, and macOS,
@@ -50,7 +50,7 @@ numerous dedicated [Zulip API](https://zulipchat.com/api) clients
 (e.g. bots).
 
 A server can host multiple Zulip *realms* (organizations), each on its
-own (sub)domain.  While most deployments host only organization, some
+own (sub)domain.  While most deployments host only one organization, some
 such as zulipchat.com host thousands.  Each organization is a private
 chamber with its own users, streams, customizations, and so on. This
 means that one person might be a user of multiple Zulip realms. The
@@ -178,11 +178,8 @@ detail.
 
 ### Redis
 
-Redis is used for a few very short-term data stores, such as in the
-basis of `zerver/lib/rate_limiter.py`, a per-user rate limiting scheme
-[example](http://blog.domaintools.com/2013/04/rate-limiting-with-redis/)),
-and the [email-to-Zulip
-integration](https://zulipchat.com/integrations/doc/email).
+Redis is used for a few very short-term data stores, primarily
+our rate-limiting system.
 
 Redis is configured in `zulip/puppet/zulip/files/redis` and it's a
 pretty standard configuration except for the last line, which turns off