Support cron-schedule-based autoscaling for MonoVertex and Pipeline vertices

[yhl25]

Summary

Numaflow autoscaling today is purely reactive, scaling between scale.min and scale.max based on pending messages and processing rate. This proposes cron-schedule-based autoscaling: users define time windows with their own min/max bounds (including 0), and the reactive autoscaler operates within the bounds of the active window.

Use cases

• DLQ draining via fallback sink: Numaflow supports a fallback sink, often pointed at a DLQ. Today, reprocessing DLQ messages requires a separate scheduled job. With cron-based autoscaling, the same MonoVertex/Pipeline can sit at min: 0 and scale up on a schedule to drain the DLQ, no extra infrastructure.
• Pre-warming: scale up ahead of predictable load spikes instead of paying cold-start lag after pending builds up.
• Cost savings: force lower bounds during known-idle windows (nights/weekends).

Proposed spec (starting point)

Extend the existing Scale struct (applies to both MonoVertex and Pipeline vertices):

scale:
  min: 0
  max: 50
  cron:
    timezone: "America/Los_Angeles"
    schedules:
      - start: "0 2 * * *"   # nightly DLQ drain
        end: "0 3 * * *"
        min: 1
        max: 5

Outside any window, base min/max apply; inside a window, its bounds override the base.

[AyushSrivastava1818]

Hi! I'd like to work on this feature if it's available.

I'll first go through the current autoscaling implementation and the existing Scale API to understand the flow, then propose the necessary changes for the cron-based scheduling while keeping the current reactive autoscaling behavior intact.

Please assign this issue to me if that works. Thanks!

[syayi]

One thing to consider, instead of defining cron schedules per vertex, should the schedule be defined once at the Pipeline level, the whole pipeline comes up/down on one clock, with each vertex still adhering to its own min/max? Would avoid vertices being on mismatched schedules within the same pipeline.

[AyushSrivastava1818]

That's a good point. Defining the schedule once at the Pipeline level would definitely simplify the configuration and avoid the possibility of different vertices ending up on conflicting schedules.

One tradeoff I can think of is flexibility. Per-vertex schedules would allow scenarios where only specific vertices (for example, a DLQ-processing vertex or a particularly expensive stage) need to scale on a schedule, while the rest of the pipeline continues using the default reactive behavior.

I'll look through the current autoscaling design and how Scale is used across MonoVertex and Pipeline before diving into the implementation. That should give a better picture of whether a pipeline-level schedule is sufficient or whether there are practical use cases that justify per-vertex scheduling.

[vigith]

@AyushSrivastava1818 please work on a sub issue at a time (not the parent) since it can give other potential contributors a chance too

ref: https://numaproj.slack.com/archives/C03GQ3AMHE1/p1784480041792079?thread_ts=1784298753.121059&channel=C03GQ3AMHE1&message_ts=1784480041.792079