aelena.com

This is just a sketch of an idea for all manner of web-based applications, LOB applications or otherwise. The idea is that requests to the server should provide or be enriched with some sort of metadata that would enable the server to inspect a given request and decide on the configured importance of that request. This could either be done from the client side of the application, which then should have some modicum of business knowledge so that all requests to the server are wrapped or enriched with some metadata describing a degree of priority, for example, or some sort of indicator.

This is not very new, as that wrapping might reming of old-style SOAP enveloping. Also the idea of some sort of metada or cataloguing of requests is similar to what you find implemented in certain frameworks, for example, actor frameworks like Akka.NET have a similar mechanism in virtue of which, system messages can jump to the top of the queue for priority processing. If we want to keep the client side free from these troubles and the necessary knowledge, other strategies can be followed. This wrapping or enriching of requests could be outsourced to some dispatcher component that centralizes and takes care of that task.

Obviously you need that this extra step does not become some sort of bottleneck when processing a lot of requests. Given that the task is well-scoped and stateless, it is easy to think of this as a fast web service, even a tcp.net windows service – if that suits your application typology -, or some cloud-based job, that could keep it’s necessary configuration or rules in a small memory cache, and even, with some extra work, be able to be reconfigured while live. In an even simpler way, we could just create some configuration database so that the server side can actually look at a request and then decide. In the simplest scenario, the URL could already give a lot of information for decision, especially if you have a well-crafted web api design. For example, you could choose to server first people who are using v2 of your api (www.mygreatcompany/api/v2/product/123) instead of those still using the v1, or you could inspect metadata to understand if your user is a paying platinum member instead of a bronze free account.

Or you could discrimate by locale. If you have 0 presence in China, and you suddenly get a lot of traffic from China, maybe you don’t want to pay that much attention to that (leaving other security concerns aside here). Similarly, in some applications you could have “system” messages that you want to have priority, for example, refreshing a piece of data held in cache immediately. To make this into a configurable, reusable mechanism probably a good way is to configure a simple map or hashtable of identifiers and assigned weights, something along the lines of this one below, even combining different aspects (URL inspection, user metadata, etc) of inspection to better decide on the business weight of a request:

Such a structure would be easy to customize in each application according to needs, so that each could roll out its own requests analyzer according to business needs. This strategy could also be used in conjunction with other patterns, such as an azure priority queue, to which the most important messages could be routed to. I am sure there are holes in this and plenty of room for improvement, but I think the idea could be interesting in many scenarios, and in some of them a simplified approach can do. Overly complicated systems are also expensive, so sometimes, some duct tape can do, at least as an spike, and then if the idea proves good, then learn and refine, of course.