Achieving performance, scalability, and high availability at the same time is very difficult. Coherence is by no means a silver bullet that will solve all these problems for you out of the box. However, it is a great tool that can be used to solve many of the problems involved and can make your job as an architect significantly less difficult.

However, whether you use Coherence or not, you should take away from this book a few general recommendations that will help you design and build scalable systems.

For one, try to avoid your application making a large number of network calls. This includes web requests, database calls, web service calls, calls to remote EJBs or COM+ components, access to shared network resources, and so on. Every network call introduces some latency, and if you are not careful these latencies quickly add up to create non-responsive, poorly performing applications.

One way to minimize the number of network calls is to use caching in every application layer. Coherence provides a great caching solution for your application objects, but is by no means the only cache you should use. You should take advantage of both the page and fragment caching provided by your chosen web server and delivery technology. You should set HTTP expiration headers properly to allow both proxy servers and web browsers to cache the content for as long as possible. If you are building a large public website, you should seriously consider using Content Delivery Network (CDN) to cache static content geographically closer to the end users. The sooner you can respond to the user's request, the better your application's performance will be, and the lower the overall load on your servers is going to be.

Even with Coherence, you should keep in mind that access to an object in a partitioned cache involves network calls, and should look for ways to eliminate them. Some of the Coherence features, such as near and continuous query caching, will go a long way to help you achieve that, so look for the opportunities to use them.

Second, try to minimize the amount of data that you need to move across the wire in order to perform some processing. Moving many megabytes of data to answer a few bytes question will take some time no matter how fast your network is, and will put significant load on all components of your applications, from application servers and network hardware, all the way to the database servers. Always ask yourself if a particular piece of functionality is moving more data across the wire than it really needs—you will be surprised how often the answer will be "yes".

To avoid that, look for ways to move the logic to where the data is instead of moving data to where the logic is. If you are using Coherence, use entry processors and parallel aggregators whenever you can. If you are not, look to leverage features of your database, such as stored procedures, that allow you to achieve the same thing.

When you do need to move data, try to do it in batches instead of object by object. Use write behind and batching features of your database when persisting cached objects. Use client-side batching and putAll when loading data into Coherence caches.

Last, but not least, make sure that you use the right tool for the job throughout the architecture.

Relational databases were designed to safeguard data on a persistent storage and to answer complex relational queries, not to be used as key-value stores or to be scalable. The same design decisions that were made to ensure ACID properties of relational databases also make them incredibly hard to scale out. While you can use sharding to scale relational databases out, you must be aware that it is a kludge we as an industry have come up with to work around their inherent limitations. You will likely loose most of the ACID properties in the process, and even such basic things as queries will become a nightmare. That doesn't qualify as the right tool for the job in my book (no pun intended).

Coherence, on the other hand, was designed from the very beginning to enable massive scale-out and high availability, and we also got improved performance for free as a nice side effect of the decision to store objects in memory. (As far as I know, absolute performance was never a design goal for Coherence—predictable, scalable performance was).

That doesn't mean that relational databases are going to go away, as Patrick pointed out in his chapter. They still have their role if you need persistence (some applications don't) or need to query your data using complex relational joins (many applications don't.) But it does mean that you should use an in-memory data grid in front of them if you need to scale out the data layer.

On a more subjective and personal note, look for technologies that can help you achieve your goals but are also fun to work with. I have had the pleasure of meeting and talking to many Coherence users, and one thing that is consistent, no matter what kind of system they built on top of Coherence, is that they absolutely loved using it. For me personally, working both with and on Coherence has been a great pleasure that I hope will continue for many more years.

A few years ago, Charles Connell wrote an essay Most Software Stinks! While I strongly recommend reading the whole essay, which is available at http://www.chc-3.com/pub/beautifulsoftware.htm, I would like to end the book by quoting a small excerpt from it:

He then goes on to define "beautiful software" and its qualities:

Coherence is beautiful software. Have fun with