Chapter 11. Scaling JAX-RS
When studying the Web, one can't help but notice how massively scalable it is. There are
hundreds of thousands of websites and billions of requests per day traveling across it. Tera-
bytes of data are downloaded from the Internet every hour. Websites like Amazon and Bank
of America process millions of transactions per day. In this chapter, I'll discuss some features
of the Web, specifically within HTTP, that make it more scalable and how you can take ad-
vantage of these features within JAX-RS applications.
Caching is one of the more important features of the Web. When you visit a website for the
first time, your browser stores images and static text in memory and on disk. If you revisit
the site within minutes, hours, days, or even months, your browser doesn't have to reload the
data over the network and can instead pick it up locally. This greatly speeds up the rendering
of revisited web pages and makes the browsing experience much more fluid. Browser cach-
ing not only helps page viewing, it also cuts down on server load. If the browser is obtaining
images or text locally, it is not eating up scarce server bandwidth or CPU cycles.
Besides browser caching, there are also proxy caches. Proxy caches are pseudo-web servers
that work as middlemen between browsers and websites. Their sole purpose is to ease the
load on master servers by caching static content and serving it to clients directly, bypassing
the main servers. Content delivery networks (CDNs) like Akamai have made multimillion-
dollar businesses out of this concept. These CDNs provide you with a worldwide network of
proxy caches that you can use to publish your website and scale to hundreds of thousand of
If your web services are RESTful, there's no reason you can't leverage the caching semantics
of the Web within your applications. If you have followed the HTTP constrained interface re-
ligiously, any service URI that can be reached with an HTTP GET is a candidate for caching,
as they are, by definition, read-only and idempotent.
So when do you cache? Any service that provides static unchanging data is an obvious can-
didate. Also, if you have more dynamic data that is being accessed concurrently, you may
also want to consider caching, even if your data is valid for only a few seconds or minutes.
For example, consider the free stock quote services available on many websites. If you read
the fine print, you'll see that these stock quotes are between 5 and 15 minutes old. Caching is
viable in this scenario because there is a high chance that a given quote is accessed more than