CODEWITHSUNDEEP
reactive-programmingevent-based-programming
Felteh
Felteh

Reputation: 53

Reactive systems - Reacting to time passing

Let's say we have a reactive sales forecasting system.

Every time we make a sale we re-calculate our Forecast for future sales. This works beautifully if there are lots of sales triggering our re-forecasting. What happens however if sales go from 100 events per second, to 0. And stay 0 for a long time? The forecast we published back when sales were good stays being the most up to date forecast.

How would you model in this situation an event that represents 'No sales happening' without falling back to some batch hourly/minutely/arbitrary time segment event that says 'X time has passed'.

This is a specific case of a generic question - How do you model time passing with nothing happening in an event based system - without using a ticking clock style event which would wake everyone up to reconsider their current values [an implementation which would not scale].

The only option I have considered that makes sense: Every time we take a sale, we also schedule a deferred event 2 hours in the future that asks us to reconsider our assessment of that sale. In handling that deferred event we may then choose to schedule further deferred events for re-considering.

Upvotes: 1

Views: 74

Answers (1)

Niall Connaughton
Niall Connaughton

Reputation: 16117

Considering this is a very generic scenario, you've made a rather large assumption that it's not possible to come up with a design for re-evaluating past sales in a scalable way unless it's done one sale at a time.

There are many different scale related numbers in the scenario, and you're only looking at the one whereby a single scheduled forecast updater may attempt to process a very large number of past sales at the same time.

Other scalability issues I can think of:

  • Reevaluating the forecast for every single new sale doesn't sound great if you're expecting 100s of sales per second. If you're talking about a financial forecasting model for accounting, it's unlikely it needs to be updated every single time the organisation makes a sale, if the organisation is making hundreds of sales a second.

  • If you're talking about a short term predictive engine to be used for financial markets (ie predicting how much cash you'll need in the next 10 seconds, or energy, or other resources), then it sounds like you have constant volatility and you're not really likely to have a situation where nothing happens for hours. And if you do need forecasts updated very frequently, waiting a couple of hours before triggering a re-update is not likely to get you the kind of information you need in the way you need it.

  • With your approach, you will end up with one future scheduled event per product (which could be large), and every time you make a sale, you'll be dropping the old scheduled event and scheduling a new one. So for frequently selling products, you'll be doing repetitive work to constantly kick the can down the road a bit further, when you're not likely to ever get there.

What constitutes a good design is going to be based on the real scenario. The generic case is interesting to think about, but good designs need to be shaped to their circumstances.

Here are a few ideas I have that might be appropriate:

  • If you want an updated forecast per product when that product has a sale, but some products can sell very frequently, then a good approach may be to throttle or buffer the sales on a per product basis. If a product is selling 50 times a second, you can probably afford to wait 1 second, 10 seconds, 2 hours, whatever and evaluate all those sales at once, rather than re-forecasting 50 times a second. Especially if your forecasting process is heavy, doing it for every sale is likely to cause high load for low value, as the information will be outdated almost straight away by the next sale.

  • You could also have a generic timer that updates forecasts for all products that haven't sold in the last window, but handle the products in buffers. For example, every hour you could pick the 10 products with the oldest forecasts and update them. This prevents the single timer from taking on re-forecasting the entire product set in one hit.

  • You could use only the single timer approach above and forget the forecast updates on every sale if you want something dead simple.

  • If you're worried about load from batch forecasting, this kind of work should be done on different hardware from the ones handling sales.

Upvotes: 1

Related Questions