Does Numaflow fit real-time decisioning with an eligibility gate?

[smedishetty1995]

Hello, gut-checking whether Numaflow is right here before we build, and curious if anyone's done something similar.

We run a batch model that picks the best time to contact each customer, scored once a day. Trouble is the decision gets locked in at list-build time, but the customer's state might change before we actually reach out. We want to re-evaluate in a stream, closer to the moment of action. Roughly: a source (periodic tick + reactive events) feeds an eligibility gate, then inference (Python model scoring contact likelihood), then rank/decide out to a queue + audit log, with outcomes streamed back as feedback.

What pulls me toward Numaflow is exactly-once and per-vertex autoscaling for spiky load.

Is this a typical Numaflow use case, or should I use streaming when a scheduler + service would suffice?

[syayi]

Hey @smedishetty1995! Thanks for evaluating Numaflow. If I understood correctly, you're running a batch model that scores customers once a day for the best contact time, but want to re-evaluate closer to the actual moment of outreach since customer state may have changed — and the pipeline shape you're describing is source → filter/gate → inference → fanout.

Numaflow can work well here, but whether it's the right tool really depends on your volume and latency requirements. Numaflow is useful when load is spiky enough that backpressure and autoscaling matter, or when your inference step is slow/expensive enough that you need it decoupled and independently scaled from the filter/gate. Any high level info on your throughput or inference time?

Also, when you mention outcomes streamed back as feedback, what does that mean?

[smedishetty1995]

Hey @syayi , thanks! Yes, you understood it right: source, then gate, then inference, then fanout.

On volume and latency: the load comes in bursts. At the top of each hour we score tens of thousands of records in a few minutes, then it goes quiet until the next hour. Smaller events (account changes, results of earlier attempts) come in all day at a low rate. The model itself is fast and cheap to run. There are also a few steps before and after the model, and each does a different amount of work, so ideally each one scales up and down on its own. The main reason I want the gate and the model separated is that the gate keeps track of recent contact attempts per customer and must never let a bad call through, while the model just needs to scale up for the hourly burst and scale back down after. We don't need split-second speed.

On feedback: every contact attempt creates a result (answered, no answer, reached the right person, promise made). Those results flow back in for two reasons. First, they update the recent-attempt counts the gate uses, so limits reflect what happened minutes ago instead of last night. Second, we total them up to see if calls made at the model's suggested times actually work better.

Given all that, does Numaflow still look like a better fit than a simple scheduler plus a service?

[syayi]

Thanks, @smedishetty1995! That should work, numaflow can take care of scaling, you don't have to worry about burst of events and the time they come at, we can scale up and down to 0 when required. Also, you can have your pre-processing and post processing steps separated from the inference step so they scale individually. On the inference part, if it's lightweight and quick you can have it on the pipeline or you can host it as external service and make a call to your model serving service from the inference vertex.

On the feedback, Numaflow can solve for this too. You can have another pipeline that processes results of the contact attempt events as they come, based on what you shared they need to be processed real time and be available for the gate step in the inference pipeline to avoid bad calls to go through.

Give Numaflow a try and let me know if you need any further help. Join our slack community - https://join.slack.com/t/numaproj/shared_invite/zt-2tflzfaxx-AeaOZtUtkZuxxTqqjL0TSg