The purpose of this example is to stress that application design is a crucial part of choosing what types of availability issues need addressing when creating a design for high availability.
The One-of-A-Kind (OaK) StoreCompany project was conceived to validate a marketing idea. It costs StoreCompany little to enter special art items into its standard catalog structure and have the items drop-shipped by the artist. The proposal made by marketing was that by using business intelligence (BI) schemes they could identify, in real time, those customers likely to buy expensive OaK items. They could also identify those types of items that would be of interest by comparing the customers' buying habits with those of other customers. The approach chosen was to give the market development team a few Linux images of their own: the datamart and business intelligence images in Figure 11-7.
Figure 11-7. Implementing high availability for StoreCompany
StoreCompany considers the availability of its online catalog store to be important to its corporate image. So the design of even the OaK prototype needed to consider high availability. Since the art items are kept in the online catalog, that aspect of this prototype inherited the existing high-availability characteristics of the catalog-ordering system, as described in Appendix B, "StoreCompany."
One of the key items being investigated with the prototype was whether this datamart/BI scheme would work at all. And if it did work, could the real-time BI query be done fast enough in most cases? The purpose of the query was to produce a pop-up window to the customer. This window contained the results of a unique catalog search of the OaK items, based on the "mined" prior preferences of this and similar customers.
The availability consideration netted down to the following conclusion: there was no special treatment for availability needed in the prototype. If the BI query produced its intended results (a catalog search results page), then the customer was directed to the search facility of the catalog ordering system. Therefore, availability from that point onwards was already taken care of. If the new Linux image failed before producing the page, the result was no different, from the customer's perspective, from the query's not returning fast enough.
A restart of the prototype's Linux images would be quite fast because the two Linux images reference only static data in the datamart.