Chapter 8 ■ CaChes and Message Queues143The other innovation message queues offer is that instead of supporting only the point-to-point connections that
are possible with an IP transport like TCP, you can set up all kinds of topologies between messaging clients. There are
many possible uses to which message queues are put.
• When you sign up for an account at a new web site using your email address, the site
typically responds immediately with a page saying “Thank you, please watch your inbox for
a confirmation e-mail,” without making you wait the several minutes that it might take the
site to reach your e-mail service provider to deliver it. The site typically accomplishes this by
putting your e-mail address into a message queue from which back-end servers can retrieve
the address when they are ready to attempt a new outgoing SMTP connection (Chapter 13).
If a delivery attempt experiences a temporary failure, then your e-mail address can simply be
placed back on the queue with a longer timeout for a re-try attempt later.• Message queues can be used as the basis for a custom remote procedure call (RPC) (see
Chapter 18) service, a pattern in which busy front-end servers can offload difficult work by
placing requests on a message queue that might have dozens or hundreds of back-end servers
listening to it and then waiting for a response.• High-volume event data that needs to be aggregated or centrally stored and analyzed is often
streamed as tiny efficient messages over a message queue. On some sites, this entirely replaces
both on-machine logging to local hard drives and older log transmission mechanisms such
as syslog.The hallmark of a message queue application design is this ability to mix and match entire populations of clients
and servers, or publisher and subscriber processes, by having them all attach to the same messaging fabric.
The use of message queues can produce a bit of a revolution in how you write programs. Typical monolithic
applications are composed of layer upon layer of APIs through which a single thread of control might pass from
reading HTTP data from a socket to authenticating and interpreting the request to calling an API to perform bespoke
image processing and finally to writing the result to disk. Every API used by that single thread of control has to be
present on a single machine, loaded into a single instance of the Python runtime. But once message queues are part
of your toolkit, you start to ask why something as intensive, specialized, and web-agnostic as image processing should
be sharing the CPU and disk drive with your front-end HTTP service. Instead of building services from large machines
with dozens of heterogeneous libraries installed, you start pivoting toward single-purpose machines grouped into
clusters that provide a single service. Your operations folks can easily start taking down, upgrading, and reattaching
the image processing servers, say, without needing even to touch the load-balanced pool of HTTP services that sit
out in front of your message queue, so long as operations understands the messaging topology and the protocol for
detaching a server such that no messages are lost.
Each brand of message queue typically supports several topologies.
• A pipeline topology is the pattern that perhaps best resembles the picture you have in your
head when you think of a queue: a producer creates messages and submits them to the queue
from which the messages can then be received by a consumer. For example, the front-end web
machines of a photo-sharing web site might accept image uploads from end users and enroll the
incoming files on an internal queue. A machine room full of thumbnail generators could then
read from the queue, with each agent receiving one message at a time containing the image for
which it should generate several thumbnails. The queue might get long during the day when the
site is busy and then grow short or empty again during periods of relatively low use, but either
way the front-end web servers are freed to return a response quickly to the waiting customer,
telling the customer that their upload is successful and that their image will soon appear in their
photo stream.