I'm not sure what you mean by continuous prediction.
Depending upon you system design, you have some concept of state, "everything you need to know, and nothing else". For instance, if features of a few order books map to your system's concept of an state, only order book events require reevaluation of your predictions.
To avoid susceptibility to "quote stuffing" or in general activity rates beyond your system's ability to keep up with out queueing, you may want to consider a clocked architecture, where you check if events arrived in the most recent interval. No event arrivals? No reevaluation required. Events arrived? Reevaluate. You will know the maximum rate at which you will need to perform reevaluation (the clock rate), and you can verify that you have adequate computing capacity for your tasks.
While I have systems responding to market-opened and market-closed events, I do not have systems that respond to the continuous passage of time.
If you use a clocked architecture, you will need to determine if it is appropriate for you trading strategy. For some strategies, the first participant gets the profit, the remaining participants get the risk. A clocked architecture would not be appropriate in this scenario. I don't work with such systems, but perhaps such an event-driven system could gracefully disengage when event rates exceed designed maximum throughput capacity.