The problem
Most data tooling assumes batches, because batches are easy to reason about: a window closes, the work runs, the result is either right or retried. Time-sensitive decisioning removes that window. The pipeline is always running, every record matters, and the two classic failure modes — losing a record and processing one twice — are both unacceptable rather than merely undesirable.
How we approached it
Make every stage idempotent, so a retry is always safe and exactly-once becomes a property of the design rather than a hope about the infrastructure.
Separate ingestion from inference, so a slow model cannot apply backpressure to data collection and lose records upstream.
Budget inference cost explicitly against the value of the decision it informs — always-on inference is a recurring cost, not a fixed one.
Instrument the pipeline so correctness is observable continuously, since there is no batch boundary at which to check it.
Where it landed
A continuously running pipeline where retries are safe by construction, the cost of always-on inference is a tracked figure rather than a surprise on the bill, and correctness is something the system reports rather than something that is discovered later.
No percentages or dollar figures appear above. These are our own products, and the structural changes described are checkable; a number attached to them would not be. We would rather publish the former than invent the latter.