User think time and asychrony

Sometimes the simple idea is the right one to use. We have a complex and highly visible (ASP.NET) web application where I am employed, and I have been the architect and technical lead for this web application since its inception. Now, to use this application, you first have to authenticate (using a standard user name and password arrangement), and will then be challenged with a form of two factor authentication.

Once all this has been negotiated successfully, the web application displays a summary (cf welcome) page containing details of your relationship with the organization. What is displayed is not important in terms of detail, but it is important that there can be a significant latency when constructing the domain objects that are of use. Sure, we employ lazy loading and AJAX judiciously, but there are other options. And significant latency here means anywhere up to 5 or 6 seconds for clients with complex or many relationships - which is a massive time span in Internet terms.

This is where a simple piece of lateral thinking was helpful (I should disclose that Alex Herzog was involved in the original discussions, and was most insightful). I gathered some statistics relating to user think time at the 2FA stage - and was astonished to see an average 'user think' of more than 10 seconds at the 2FA challenge. Now, this does not mean the 2FA needed to be redesigned; it was (still is) accepted as sufficient for our purposes and there was no appetite for any action in this area. But look at that temporal window - its almost double the domain objects construction time for the home page - it seemed almost criminal not to use it.

So the idea formed that this window could be used to 'fork' a one way web service call, that invoked the domain object build machinery to perform necessary object construction. It can't be done sooner than the 2FA challenge, as we need to basically authenticate a user before we devote any server resources to them. Also, executing as a one way service means that we don't have a session to manipulate - the place where our domain objects are normally stored. But we do have a distributed cache available, and by dint of interfaces, are able to have a session that behaves like the real thing but is distributed cache resident.

All that needs to be done to connect all this together for the home page is to include some simple Presenter (the web application is MVP based) logic in the presenter associated with the 'authenticated' master page, to transfer objects from the distributed cache to the (now available) session, and it's done. Of course, there are exceptions and errors to consider, and that is handled, but explaining the nature of that is not that relevant.

It's simple, almost elegant, and allows the welcome page to remain relatively trivial and with an excellent performance profile. Other options were considered, but this approach remains in use today - the 'customer genesis handler'.