Subjugating Temporal anomalies to satisfy software’s Prime Directive
Having just read one of Howard Dierking’s latest posts regarding how we reason about time when it comes to software, I am reminded about the benefits that one way messaging and publish / subscribe can bring to the table. It stands to reason that we all want our code to execute faster and our applications to respond to their users in a timely fashion; ‘slow’ is not a word users or developers alike want to hear when discussing or describing their systems. Howard’s post is a discussion that came out of his reading a book by Steven Seow titled “Designing and Engineering Time: The Psychology of Time Perception in Software”. I personally haven’t read the book however my interest in doing so has certainly been raised. I am interested here in turning the architectural spotlight onto the strategies for managing time.
Howard includes the following table in his post (the first two columns), demonstrating how perceptions of time in software / human interaction can be managed effectively. As my mind turned to thinking about publish subscribe and one way messaging I decided to add another column to this table clarify my thinking.
| Performance Dimension | Management Strategy | One Way Messaging Pub / Sub Strategy |
| Actual Performance – the precise time durations for completing a task | Operational Management – purely technical strategy (e.g. change the way it works to make it faster) | Let’s push aside algorithmic tweaking designed to speed up computation for just a moment and consider this aspect from a scaling / throughput perspective. In systems that attempt to address this through stateless web services, the strategy is one of scaling out the web servers. If we bring durable queuing into the focus then we can rather more cheaply apply divide and conquer, with patterns such as ‘competing consumer’. In terms of NServiceBus the Distributor is an excellent choice here. Again this is looking at it from an architectural viewpoint. |
| Perceived Performance – the approximate duration for completing a task as experienced by the user | Perception Management – make the task feel like it takes less time (examples include distractions, progress indicators, etc.) | Sending commands or messages to the server for processing and distract the user by maintaining UI state as though the command had been processed. One example is showing blog comments to the submitting user only, whilst waiting for the moderator to approve it. |
| User Tolerance – based on expectations, the approximate duration threshold where anything beyond will be considered slow by a user | Tolerance Management – focus on making users more tolerant of a longer duration when it cannot be shortened or “disguised” | Initial immediate response followed by a subsequent response via a different channel than that sent the message / request. Examples such as Amazon purchases that provide an immediate response and then provides confirmation email. |
In request / response systems, often the focus goes into that described in row 1 column 2 above; that is we tend to narrow in on speeding up our code, substituting for faster implementation technologies or even scaling up our hardware. In the case of stateless Web Services it’s also common to scale out the web servers. With one way messaging and NServiceBus we can increase our throughput and speed (both real and perceived) by scaling out our services and what’s more this can be achieved relatively cheaply with commodity hardware.
It’s also worth noting that the effects of implementing durable queues play’s into the Reliability aspect of the system and when those queues are placed physically adjacent with task based smart client applications that both send and receive messages, then it’s possible to create the perception that work is submitted immediately; potentially it may be repudiated later if there is something wrong with the submission itself. Maintaining a low number of these repudiated work submissions (command / messages) can increase the tolerance levels and the perceived improvement in speed in getting through the work itself.
