Week 2: Dynamic Scheduling Foundations (Days 6–10)

Why This Matters

Last week, schedules lived inside Java method annotations. That is fine for a classroom demo. It collapses the moment a product manager asks, “Can we move the reconciliation job from 2 AM to 3 AM without a deploy?” Shipping a JAR for every cadence change is how early systems age into change-request queues — not how Airflow, Quartz, AWS EventBridge, or Kubernetes CronJob operators work.

Those systems treat schedules as data: durable records that operators create, pause, retarget, and audit. GitHub Actions stores workflow crons in YAML that CI can edit without recompiling runners. Stripe’s billing cycles are configuration rows, not hardcoded timers in payment workers. Chronos — this week’s project — follows the same contract: TaskDefinition rows in an RDBMS, a REST catalog for mutations, a dynamic binder that turns ACTIVE rows into Spring ScheduledFutures, and Runnable / Callable wrappers that normalize execution into a result table.

What changes in your mental model is subtle but permanent. Scheduling stops being “a method that fires” and becomes “a write path with lifecycle.” If definitions are not durable, searchable, and activatable, nobody can answer what will fire at 02:00 across the fleet — which is the question on-call engineers ask when something goes wrong before sunrise.

At ultra-scale the insight sharpens: the schedule catalog is a control plane. Workers may multiply; queues may fan out; locks will come later. The catalog remains the source of truth for what exists. Get the model wrong now, and every later distributed feature becomes a retrofit.

Agenda

1. Why static @Scheduled is a product bottleneck

2. The task definition model as a system contract

3. RDBMS persistence for schedules (transactions, indexes, audits)

4. REST catalog: CRUD plus activate / pause as lifecycle ops

5. Component architecture of Chronos

6. Dynamic binding control flow: DB → cron → execute → record

7. Definition and execution state machines

8. Runnable vs Callable as execution interfaces

9. Fit in the 60-day distributed scheduler roadmap

10. Build, verify, assign, and mastery checklist

Core Concepts

From Code Timers to Catalog Entries

Week 1 wired triggers with @Scheduled(fixedRate|fixedDelay|cron). The compiler baked intent into bytecode. Chronos inverts that: intent lands in a table, and a runtime service binds eligible rows to Spring’s TaskScheduler.

Think of the difference between a playlist burned onto a CD versus a streaming library. The CD cannot change mid-flight; the library can. Production ops teams need the library. Redeploys become risk events — configuration changes should not require them.

The non-obvious implication for system design: create/update is now part of the scheduling surface. Validation, uniqueness, and state transitions belong in services — not only “does the cron fire.” Invalid cron on activate must fail loudly before a ghost ScheduledFuture exists with no matching row.

Definitions Are Contracts

A TaskDefinition answers four operational questions: