Browse Prior Art Database

Interrupting processing of in-flight events on the receipt of a superseding event

IP.com Disclosure Number: IPCOM000247074D
Publication Date: 2016-Aug-02
Document File: 3 page(s) / 201K

Publishing Venue

The IP.com Prior Art Database

Abstract

In processing systems, it may be of benefit to cancel current items being processed within a workflow, based upon a newly detected superseding event. This article describes a system capable of performing this action, with an example being a trading platform reacting to fluctuating stock prices.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 3

Interrupting processing of in-flight events on the receipt of a superseding event

Processes responding to a stream of events may make decisions in response to an event that have costs associated with them. For example, an algorithmic trading system that receives stock tick events from a exchange will make decisions to buy or sell stocks depending on the latest stock price in the event.

    There exists a timing window where such an event is still being processed, but a new superseding event arrives for processing. Returning to our example, the stock price in the new event may be more or less favourable than the one being processed. This new price may cause the trading algorithm to make a different decision than it has made as a result of the event currently being processed. If the event being processed is allowed to complete without reflecting the new price then the algorithm may cause the owner of the system to lose money. Ideally, the system would be able to cancel processing of an in-flight event if a superseding event arrived before that processing could be completed. In our example, the ideal outcome is that the sell is cancelled and the trading algorithm is allowed to hold on to the shares to see how far the price goes up. The described use case is bespoke to a trading system, though there are alternative use cases where the same solution could be used.

    Such a system could be realised through internally tracking events that are currently being processed by the system and pre-processing subsequent events so that the system can identify if the new event is a superseding event for one that is currently being processed. If a superseding event is detected, the system stops the processing of the current event and starts processing the superseding event instead. In some cases the system may not be able to stop the processing of the current event, but is able to nullify the results of allowing the processing of that event to complete.

    To enable this the system must be able to identify which events are being processed by the system and be able to match a subsequent event to an event currently being processed by the system (if a matching event is currently being processed). In this example, the system can maintain a mapping of stock symbols to a thread that is currently processing an event for that stock symbol.

    In order to do this, all events will have to be pre-processed first; if the events are arriving through a publish/subscribe system, then...