For instance suppose I marked Pricer.price(Order) as an asynchronous operation then when loading OrderProcessor the AsynchronousTransformingClassLoader would notice that processOrder calls an asynchronous method and transform processOrder appropriately using futures and addressing concerns that Sam raised about errors occuring early in the pipeline.

Event driven architectures have quite a simple structure and therefore the number of types of transformation would be quite small.

I’d like to end this with an observation: When you look at the original processOrder and add the new piece of information that Pricer.price(Order) is slow you do not add much information to the description. I think the amount of change you need to make to a program to accomodate this new change should be of comparable size to the size of the change, and if this is not so then something is wrong with the model. In this case the model lacks the ability to concisely express asynchronousness.

The impression I get from this article (I may be wrong) is that the message isn’t added to the notification queue until after the persisting queue is finished processing the message. So the three stages of order processing are still sequential, we’ve just added capability for more concurrent processing of other orders.

However, I’m not sure I understand the benefits here. I’ll attempt to translate Dan’s example into a more concrete breakdown.

We have three stages of order processing: Pricing, Persistence and Notification. Pricing is an expensive operation, requiring 5 time units. Persistence is cheap, only requiring 1 time unit. Notification is moderate, requiring 3 time units. So, all in all, processing an order requires 9 time units.

Now, imagine we have ten workers and fifty orders come in concurrently. Ten can be processed at a time, and the total time to process the fifty orders is 45 (9 time units / round * 5 rounds) time units.

Alternatively, consider those workers instead handle the three queues mentioned by Dan. Let’s divvie them as 5 Pricers, 1 Persister and 3 Notifier. The tenth worker is accepting the requests and placing the initial message on the Pricer queue.

When the fifty concurrent requests arrive, they are all placed on the Pricer queue immediately (not quite, but it’s safe to assume the dispatcher worker can fill the queue faster than the pricers can deplete it). Five are taken off the Pricer queue and 5 time units later added to the Persister queue. At this point, five more are taken off and processed. In the ensuing five time units, the persister worker has handled all five requests (1 time unit per request) and passed them on to the Notifier queue. So we see the one persister keeping up with the five pricers. Five more requests are placed on the persister queue and five more taken off the pricer queue. Also, the persister has been placing requests on the notification queue at the rate of one every time unit. The three notifier workers are pulling these off in turn—by the time the persister has put a fourth request on the notification queue, the first notifier has finished the first request and can grab that one. So the notifiers are also keeping up. Every five time units, the pricers consume five requests of the pricer queue and the others are managing the previous requests apace. After 50 time units all 10 rounds of 5 requests have been processed by the pricers. 5 time units later, the persister queue has finished its processing. 3 time units later the last notifier finishes its requeust. Total time: 58 time units.

Isn’t 58 > 45?

Jacob Fugal