Sunday, June 21, 2009

Real Life Caching

The thought behind this post comes from the rich pageant of daily life with Madame. Yesterday morning we were discussing when she should visit her mother (a sprightly 96 year old who lives about 1,000 miles from us). So it was a matter of looking for decent airfares, timing the visit to coincide with my absence, minimizing the flight time (it is always requires a change in either Chicago or Detroit).. What you may wonder is relevant about this in architecture. It all has to deal with the location of the process, and the location of some of the data required to complete the process.

The computer was in her home office – up a flight of stairs from the main living areas of the house. Her purse was down in the kitchen. She had dutifully retrieved her credit card from her purse prior to starting the transaction (pre-cached the data), and carried it upstairs. Because of where I work, I almost always try to ensure that bookings are made on Travelocity.com – keep all possible revenue in the family.

So the process goes fairly smoothly – Madame is using my Travelocity account to make the booking (easier than creating a new one at that moment). Of course this would be a security violation, so let's say, I was acting as the operator for this purpose! We get all the way through the process (well almost) when we realize that her frequent flier number is not in the account anywhere. Also that data has not been cached anywhere (not in her head, not by bringing the physical card to the point where the transaction is being executed.) So an IO request is issued – resulting in the slow IO processor (me), walking from her office, downstairs to her purse, finding it, and returning the whole purse. Why the whole purse you ask? One reason is privacy – it is hers and I don't access its contents without permission (PII rules). Second is that I don't know what other esoterica might be needed, so I want to save my weary legs – and not have to make another trip to the purse data store (which by the way is a heap storage model).

The IO request is completed. Madame parses the purse data structure until she finds the relevant card, she then types in the number and completes the transaction.

As always with these stories there are a couple of questions:

  • Would it have been more sensible for her to bring the whole purse data structure instead of just caching the credit card? In hindsight, yes. But how would she make that determination. The stairs are steep and it is a long way. The purse could be heavy (too much payload) and unwieldy.
  • Should I have brought the whole purse or just the needed card, or better still a lightweight interpretation of the number (she didn't need all of the information on the frequent flier card)?
  • Does it make sense to cache the whole content of her purse in any room where she might execute transactions? After all with wi-fi that could be anywhere, including outside the firewall (i.e. in the garden or yard)? What about security? The gardeners and the maids (would that we were so lucky!) would then have access to the cached data. That could be troublesome.
  • Is the network transport reliable? Could I have been distracted in the bringing of the data back upstairs – through answering the telephone, needing some refreshment prior to attacking the stairs, pure absent-mindedness or what?

Of course the point isn't to think about home processes much – we will do things that seem expedient without a whole lot of thought. But when designing systems, we have to think quite carefully about these kinds of things. By putting them in this sort of context, it can sometimes help to think things through.

And, oh yes, this is not really architecture – it is design. However, there are patterns that emerge, and they become important aspects of architecture.