Distributed Job Scheduler  ·  View 08 of 20  ·  Structure

Integration Surface

Three inbound APIs, deliberately separated, and four outbound target classes.

Editable source SVG draw.io All views
Inbound Schedules console Tenant CLI / IaC Tenant SDK Outcome callback Scheduled Trigger Service Management API CRUD, pause, dry-run History API per-fire record Privileged API backfill, horizon, quota Outbound Tenant HTTP target Tenant queue Platform executor Monitoring HTTPS apply REST signed attempt enqueue handle signals Integration Surface — Who Calls, Who Is Called Application we own External / third party Interface / broker Security / platform Queue / topic synchronous event / async Three inbound surfaces, deliberately separated: authorship, reading history, and the privileges that multiply work. The audit and billing exports are omitted here; they appear in views 10 and 16. v 1.0 · owner Platform Architecture · date 2026-10

Decisions

  • Authorship, history and privilege are three APIs rather than one, because they need three different authorisation stories (ADR-15).
  • The outcome callback is an inbound integration with its own verifier, not a trusted internal path: anything a tenant's executor can send is untrusted (ADR-14).
  • Declarative apply (CLI and IaC) is a first-class surface, because a schedule that exists only in a console is a schedule nobody can review.

Assumptions

  • Four target classes cover the estate: tenant HTTP, tenant queue, platform executor, and the no-op case where the fire is only recorded.

Deliberate omissions

  • The audit and billing exports are omitted here and appear in views 10 and 16.