20 views, in reading order. Every view ships three ways: an HTML page, an SVG that re-opens in diagrams.net fully editable, and draw.io source.
The scheduled-trigger service behind a developer platform's "every weekday at 09:00" box. Read it in seven acts: what sits inside the boundary, who it is for and what they get to do, how it is put together, what it stores, what happens when an instant comes due, how it is operated, and why it is safe. Every rate, latency and threshold here is a stated assumption, chosen to be arguable rather than measured — the package is a design, not a report on a running system.
The timing plane decides; the execution plane works; and the only thing crossing between them is an immutable, uniquely-keyed fire record that is committed before it is delivered.
Every developer platform ships a four-word scheduling box, and behind it is a problem that looks solved and is not. A multi-tenant timer fleet has to fire tens of millions of independent triggers at the right instant while a partition owner is being replaced, a node's clock is wrong, a zone is draining, and a tenant has just resumed four thousand triggers that slept through a day. The convenient implementation — fire from a node's system clock and record the result afterwards — fails in three ways that each look like success at the time. It fires early when a clock runs fast, producing work that reads a window of data which has not closed yet and reports a short answer. It loses fires that happened but were never recorded, which no amount of later reconciliation can recover because the record that was supposed to prove it is the thing that is missing. And when it comes back from an outage it releases everything it owes at once, turning a scheduling incident into an incident for every executor downstream. On top of those, it cannot answer the one question tenants actually ask — "did my job run last night?" — because a job that did not run produces no signal at all, in a service that is up, healthy on every dashboard, and silent.
Separate the plane that decides from the plane that works, and make the scheduler's durable output a decision rather than a result. A partition owner asks a time source for a bounded uncertainty interval, scans its share of a time-ordered due index for instants due at or before the lower bound of that interval — so it is deliberately ε late and never early — applies the trigger's declared overlap policy, and commits an immutable fire record whose primary key is derived deterministically from the tenant, the trigger and the scheduled instant. That key is the idempotency key, so two owners mid-handover compute the same one and the second insert loses to a uniqueness constraint instead of producing a second fire. Only then is anything dispatched, through one of three separate queues — on-time, catch-up, backfill — each with its own drain rate, so a backlog released by a recovery is rate-shaped rather than flooded and recovery is deliberately slower than the failure that caused it. Delivery is at-least-once with the key attached and a published residual duplicate rate, not an exactly-once claim nobody can verify. Everything derived — the due index, the caches, the fire history — is a rebuildable projection of a registry and a ledger that are the only systems of record, and the rebuild runs continuously in a shadow partition rather than waiting to be needed. What the tenant gets is a per-fire record with its scheduled, decided and dispatched instants and the cause of any non-dispatch; what the platform watches is the age of the oldest undispatched due instant, which is the only signal that can tell a working scheduler from a silent one.
The fire record is written before any attempt is made, so a dispatcher that dies mid-attempt loses an attempt and never a fire. Of the two orderings available, one failure is unrecoverable and the other is a retry; the ordering of two writes decides which one the system can have.
ADR-01Two planes, separately deployed and scaled, sharing only the state of record. Console traffic, a bad management deploy and an identity outage become latency incidents instead of missed fires. One write region, because two regions evaluating "is the previous run still going" produce two answers no key reconciles.
ADR-02The fire's primary key is (tenant, trigger, scheduled instant, sequence) — computed, not generated. Split ownership becomes a constraint violation rather than a detection problem, which is what lets leases be short, takeover fast, and leader election imperfect.
ADR-03The node clock is untrusted. The scheduler takes a bounded uncertainty interval, waits it out, and scans for instants due at or before its lower bound — paying about 10 ms of deliberate lateness to make earliness impossible. A node whose uncertainty exceeds the ceiling sheds its leases rather than firing on a clock it cannot justify.
ADR-04One due-index row per trigger, holding one next instant, recomputed on advance against the named zone. An amendment, a pause, a validity change and a time-zone database update are all picked up with no invalidation sweep, because nothing was cached to invalidate — and dry-run is exact rather than indicative.
ADR-05Every trigger declares its missed-fire policy from a closed set of three, defaulting to firing once for the most recent missed instant. A billing run and a cache warm have opposite correct answers and look identical to the platform; the only party who knows which is which is the tenant, and the only time they can say so is in advance.
ADR-06Expression plus IANA zone, resolved at computation, with declared rules for the day a time does not exist and the day it happens twice, and the time-zone database version recorded on every fire — so a disputed instant six months later is explainable from data rather than from memory.
ADR-07An instant older than the catch-up horizon is recorded as expired with its cause and never dispatched, whatever the tenant declared — the one place the platform overrules them. Caught-up fires carry their original scheduled instant, because the work reads a window defined by it.
ADR-08Three queues with independent drain rates and a per-tenant catch-up cap, plus a published shedding order: backfill, catch-up, over-quota, then on-time. A one-hour backlog takes about ten hours to drain, which is the price of not making the recovery into the next outage for every executor downstream.
ADR-09Sixty per cent of fires land in the first second of a minute. Deterministic opt-out jitter smearing and the lateness budget absorb a 45,000/s peak that lasts five seconds an hour, instead of provisioning eight times the steady-state capacity to be idle for the rest of it.
ADR-10The due index, the leases and every cache are projections of the registry and are not backed up. A shadow rebuilder recomputes and compares continuously, and partition ownership moves routinely rather than only during failure — because a recovery path that is only exercised in an incident is a claim, not a capability.
ADR-11Overlap is enforced against recorded outcome state bounded by a window. A fire still unknown at the end of its window counts as finished, and the decision is recorded. The alternative — treating it as still running — turns one lost callback into a permanently stopped trigger that looks perfectly healthy.
ADR-12The paging signal is oldest undispatched due instant age, because a scheduler that is up and not firing passes every other check. The same measurement, per fire and per trigger, is a tenant-facing product surface — so "did my job run" is answerable without reading platform logs or opening a ticket.
ADR-13Targets must be verifiably owned, checked at definition and again at dispatch; no tenant request reaches the fire zone; and credentials are minted per attempt with the attempt's lifetime. A service that will make authenticated requests to any URL on a timer, with a retry budget, is an attack tool until ownership is proved.
ADR-14Backfill, horizon extension and quota change are grantable apart from trigger authorship, and audited with prior values. Each of them is most attractive at the moment judgement is worst, which is during the incident — so the routine role's worst case stays routine.
ADR-15The tenant payload exists in two stores, encrypted under a per-tenant key, and never in history, reporting, metrics or logs. The platform cannot classify what it does not interpret, so it handles the payload as the most sensitive thing it could be and debugging starts from a fire key.
ADR-16Clouds, queue services, container runtimes and consistency models will all be replaced inside this platform's life. These are the properties that should outlast them.
"The timing plane's product is a committed decision" is a statement about where authority lives, not about which store holds it. Spanner, a successor nobody has shipped, or a different strongly consistent store can each satisfy it, and every decision downstream — the key as the deduplication mechanism, lanes as retries against records, history as a projection — survives the substitution unchanged.
Naming a fire from its own semantics rather than generating an identifier for it is the oldest reliable trick in distributed systems. It depends on no store, no broker and no transport, and it is why imperfect leader election is affordable here. What could change is executors' willingness to deduplicate — which would call for an added suppression store, not a redesign.
Scheduled work reads windows defined by its scheduled instant. That is a property of the work, not of the scheduler, and no improvement in clocks makes an early fire safe. If clocks get better, ε shrinks and the deliberate lateness disappears on its own; if they get worse, the lease-shedding ceiling catches it.
A system that accumulates obligations while it is down and then discharges them into dependencies it does not control has a feedback loop into its own failure. That is control theory, not engineering fashion. The cap's value should move with measured executor capacity; the existence of a cap should not.
Any system whose failure produces no output is invisible to health checks, forever. Alerting on the distance between what should have happened and what did is the only class of signal that sees it, and that remains true whatever the monitoring stack looks like.
Collecting, in advance, the information a system will need to make a decision it cannot make correctly during an incident is a general property of operable systems. Here it is the missed-fire policy; elsewhere it is a failover preference or a data-loss tolerance. The mechanism is configuration; the principle is foresight.
Every figure below is a stated assumption. They are listed with the mechanism that is supposed to deliver them and the view where that mechanism is drawn, so a reviewer can disagree with the number and the means separately.
| Quality | Target | How it is met | View |
|---|---|---|---|
| Fire punctuality | p50 ≤ 1 s, p99 ≤ 5 s, p99.9 ≤ 30 s of lateness | Due scan at 1 s tick on leased partitions, with the dispatch lane's drain rate sized for the mean rather than the peak | 12 |
| Earliness | Zero at every percentile | Scan for instants due at or before the lower bound of the clock's uncertainty interval; ε is waited out, not averaged | 12 |
| Degraded punctuality | p99 ≤ 60 s for up to 10 minutes during zone loss or reassignment | Partitions spread across three zones; reassignment exercised routinely rather than only on failure | 15 |
| Dispatch plane availability | ≥ 99.95% monthly, measured as due instants dispatched inside their p99.9 budget | Punctuality as the availability definition; stateless dispatch tier scaled independently of the timing tier | 06 |
| Control plane availability | ≥ 99.9% monthly, failing independently of the fire path | Separate deployment, scaling and service accounts, sharing only the state of record | 06 |
| Trigger population | 20,000,000 active triggers across 50,000 tenants | 256-partition keyspace with one due-index row per trigger; partition count changeable online | 07 |
| Steady-state throughput | 500,000,000 fires/day — 5,800/s mean | One transactional fire insert per fire; lane queues with declared drain rates | 09 |
| Peak throughput | 45,000 fires/s for 5 s at the top of the hour | Deterministic opt-out jitter smearing plus the lateness budget, instead of provisioned peak capacity | 14 |
| Clock uncertainty | ε ≤ 10 ms; leases shed above 100 ms | Bounded-uncertainty time source; per-node ε recorded at lease grant and alerted per node, not averaged | 12 |
| Duplicate dispatch | ≤ 1 in 10^6 fires delivered more than once | Deterministic fire key as the ledger primary key; executors deduplicate on it | 11 |
| Durability | RPO 0 in-region; cross-region RPO ≤ 15 s | Synchronous three-zone replication for registry and ledger; asynchronous standby replica | 15 |
| Recovery time | RTO 5 min dispatch plane, 30 min control plane; partition reassignment ≤ 15 s p99 | Declared region promotion; short leases made safe by the fire key; routine reassignment | 15 |
| Catch-up bound | Horizon 1 h default / 24 h max; catch-up ≤ 10% of tenant quota | Horizon filter ahead of the policy; separate catch-up queue with its own drain rate | 13 |
| Configuration propagation | Create, amend, pause, resume, delete effective within 5 s p99 | Recomputed due-index row written in the same transaction as the version | 09 |
| History | 90 days queryable, 13 months archived; 30-day single-trigger query p95 ≤ 500 ms | Bigtable projection keyed tenant#trigger#instant with TTL; archive-class object storage beyond it | 10 |
| Detection | Oldest undispatched due instant > 60 s pages immediately | Derived per-partition metric from the due index, alerted independently of process health | 16 |
| Cost | ≤ $0.60 per million fires at steady state | Mean-sized capacity, no per-trigger always-on resource, tiered history, retry and catch-up charged to the originating tenant | 16 |
The prototype's job is to falsify the two central claims — that imperfect leases plus a deterministic key really do make duplicate fires harmless, and that a bounded clock lets the scheduler be reliably late and never early — on one tenant and a few hundred triggers, not to build a platform.
| Risk | If it lands | Response |
|---|---|---|
| An executor that cannot deduplicate on the fire key | At-least-once stops being a contract and becomes a defect: a duplicate fire produces duplicate work, and the whole leases-may-be-imperfect argument collapses into a correctness problem | Make deduplication an onboarding requirement with a conformance test rather than a documentation note; publish the duplicate rate on the target's own page; and keep a platform-side suppression store as a costed Phase 2 option for targets that genuinely cannot. |
| Fleet-wide clock drift, where ε is wrong everywhere at once rather than on one node | Lease-shedding has nothing to compare against, the clock gate approves a bad interval, and the design's central guarantee — no early fires — fails silently and uniformly | Alert on per-node ε rather than an aggregate, cross-check the time service against the store's commit timestamps as an independent source, and treat a correlated ε excursion as a platform incident with scheduling suspended rather than degraded. |
| The missed-fire default is wrong for most tenants, and they accepted it without reading it | Either duplicated billable work or silently skipped work, discovered by a customer, with the platform's correct behaviour as the explanation — the trough in view 05 | Instrument override rates by tenant segment and treat a high override rate as evidence the default is wrong; show the policy's consequence in a sentence at the point of choice; and make dry-run replay what each policy would have done to the last recorded gap. |
| The oldest-undispatched-due-age alert is loud during every legitimate catch-up drain | The one signal that detects the system's characteristic failure becomes the one the on-call rotation learns to ignore, which is worse than not having it | Compute the metric separately per lane so a catch-up drain does not mask an on-time stall, suppress it against a declared drain with an expected completion time, and page on the on-time lane alone. |
| Recomputing instants for 20 million triggers every cycle becomes the scaling wall | Scan cost grows with the trigger population rather than with the fires actually due, and punctuality degrades as the population grows rather than as load does | Measure compiler cost per trigger per cycle from day one as a first-class capacity metric; keep the short-horizon materialisation variant of ADR-05 costed and ready, since it is a localised change to the due index's contract and leaves the ledger, the key and the lanes untouched. |
The architecture behind one small box in a developer platform's settings screen: "every weekday at 09:00". The one-pager is the argument in fifteen minutes; the decision record is the same argument with its working shown, sixteen decisions deep.
Status of this document. This is a design, not a report on a running system. Every rate, latency, ratio, threshold and retention figure is a stated assumption, chosen to be defensible and arguable rather than measured. The operating context assumed throughout is a developer platform with 50,000 tenants and 20 million active triggers, firing 500 million times a day at a mean of 5,800 fires a second, with 60% of all fires landing in the first second of a minute and the top of the hour carrying eight times the mean minute — a design peak of 45,000 fires a second for five seconds. Punctuality is assumed at p50 ≤ 1 s, p99 ≤ 5 s and p99.9 ≤ 30 s of lateness, with zero tolerance for earliness at any percentile; the clock uncertainty bound is assumed at ε ≤ 10 ms with leases shed above 100 ms; the residual duplicate dispatch rate is assumed at 1 in 10^6. Where a number came from nowhere, it is marked as an assumption in the view cards and in the records, and a reviewer should treat each of them as an invitation to disagree.
The boundary that defines the architecture, and the two decisions that follow from it directly.
ADR-01The scheduler's durable output is a committed fire record, written before any dispatch attempt ADR-02The control plane and the timing plane share only the state of record, and there is one write region ADR-03Idempotency lives in the data model: the fire's primary key is the idempotency key, and delivery is at-least-onceWhat time it is, how wrong that might be, and what a wall-clock expression actually means.
ADR-04The node clock is untrusted; dispatch waits out a bounded uncertainty interval, so lateness is a budget and earliness is a bug ADR-05Recurrences are recomputed each cycle from a versioned definition, not materialised ahead into the due index ADR-07Wall-clock recurrences resolve against a named zone with declared DST rules, and the time-zone database version is recorded on every fireWhat a trigger does about the fires it missed — declared before it misses them, not decided during the incident.
ADR-06The missed-fire policy is declared per trigger before the outage, and defaults to firing once for the most recent missed instant ADR-08A catch-up horizon bounds every missed-fire policy, and the original scheduled instant travels with the fire ADR-09Catch-up, backfill and on-time fires use separate queues with a per-tenant catch-up cap and a published shedding order ADR-12Overlap is enforced against recorded outcome state, with `unknown` as a first-class terminal state bounded by a windowAbsorbing the top-of-hour peak, and treating the due index as something rebuilt rather than restored.
ADR-10The top-of-hour peak is absorbed by opt-out jitter smearing and the lateness budget, not by provisioned capacity ADR-11The due index is a rebuildable projection, verified continuously by a shadow rebuild rather than backed upWhat the tenant can see, what a schedule is allowed to point at, and who is allowed to multiply work.
ADR-13Fire history is a tenant-facing product surface, and the platform alert is oldest undispatched due age ADR-14A target must be verifiably owned by its tenant, no tenant request reaches the fire zone, and dispatch credentials are minted per attempt ADR-15Backfill, horizon extension and quota change are grants separate from trigger authorship ADR-16Tenant payloads live only in the registry and the ledger, encrypted under a per-tenant key, and never in evidence or logsGoogle Cloud was chosen for this exercise for two reasons that point the same way. The first is rotation: across this repository's use cases Microsoft Azure and self-hosted open source dominate, with Amazon Web Services next, and Google Cloud carries the smallest share — six of forty-four packages before this one. Reaching for the same cloud each time teaches a service catalogue rather than architecture. The second reason is that this particular topic genuinely belongs here. A scheduler's hardest requirement is a defensible answer to "what time is it, and how wrong could that be", and this is the platform that exposes a bounded clock-uncertainty interval on a transactional store rather than asking the design to assume one. ADR-04 is the decision that depends on it, and it would read as hand-waving on a stack that cannot report its own clock error. Everything else below is replaceable; the requirement document deliberately stays vendor-neutral so that it survives a change of cloud.
| Capability | Choice | Origin | Credible alternative | Why this one | Record |
|---|---|---|---|---|---|
| Trigger registry, due index, fire ledger | Spanner regional instance, synchronous across three zones, commit timestamps as time authority | Google Cloud | CockroachDB or YugabyteDB self-hosted; DynamoDB with a separate time service; Azure Cosmos DB with strong consistency | One store that enforces the fire key's uniqueness constraint and reports bounded clock uncertainty — the two properties ADR-01, ADR-03 and ADR-04 all depend on | ADR-01 |
| Bounded-uncertainty time | Platform time service plus Spanner commit timestamps, with per-node ε recorded at lease grant | Google Cloud | AWS Time Sync with clock bound; a self-run PTP fabric; chrony with a measured error estimate | The decision to wait out ε rather than fire at the earliest permitted instant needs a source that reports its own error, not one that is merely accurate | ADR-04 |
| Control, timing and dispatch planes | Cloud Run services, separately deployed and scaled, with distinct service accounts | Google Cloud | GKE workloads; ECS or Fargate; Azure Container Apps | Independent scaling and deployment is the mechanism of the plane split, and leases make long-lived instances unnecessary | ADR-02 |
| Dispatch lanes | Three Cloud Tasks queues per region with independent rate and concurrency | Google Cloud | SQS with separate queues; RabbitMQ with per-queue limits; Azure Service Bus | Per-queue dispatch-rate control is exactly the throttle the catch-up cap needs, and it is enforced by the queue rather than by application code | ADR-09 |
| Outcome events | Pub/Sub for correlated outcome events from the platform executor | Google Cloud | Kafka; SNS and SQS; Event Hubs | Decouples the executor's reporting from the dispatch path, so a slow reporter is not a slow dispatcher | ADR-12 |
| Fire history | Bigtable projection keyed tenant#trigger#instant with a 90-day TTL | Google Cloud | DynamoDB with TTL; Cassandra; Azure Table Storage | 500 million rows a day of append-mostly evidence with a prefix-scan read pattern and native expiry | ADR-13 |
| History archive | Cloud Storage, archive class, 13 months, dual-region | Google Cloud | S3 Glacier Instant Retrieval; Azure Blob archive tier | Retention without query cost; the archive is for obligations, not for answering questions | ADR-13 |
| Lateness and cost reporting | BigQuery for lateness facts, shadow divergence and cost per million fires | Google Cloud | Snowflake; Redshift; ClickHouse self-hosted | Keeps punctuality analysis entirely off the fire path, including during the incident it is being used to diagnose | ADR-11 |
| Dispatch identity | Workload identity tokens minted per attempt, scoped to the trigger, verified by the target's issuer check | Google Cloud | SPIFFE/SPIRE with short-lived SVIDs; AWS IAM Roles Anywhere; Azure managed identities | A credential whose lifetime equals an attempt reduces a standing grant to a seconds-long one | ADR-14 |
| Payload encryption | Cloud KMS per-tenant keys, decrypted only in the dispatch path | Google Cloud | HashiCorp Vault transit; AWS KMS; Azure Key Vault with an HSM-backed key | Per-tenant keys make deletion enforceable by key destruction rather than by trusting every copy to be found | ADR-16 |
| Perimeter and egress | VPC Service Controls around the data stores; egress only from the attempt runner | Google Cloud | AWS PrivateLink and SCPs; Azure Private Endpoints with a firewall | One component with egress is an egress policy small enough to audit | ADR-14 |
| Observability | Cloud Monitoring for due-age and lateness, Cloud Logging with fire keys and no payloads | Google Cloud | Prometheus and Grafana; Datadog; Azure Monitor | The alert is a derived measurement (oldest undispatched due age), so it needs a metric pipeline rather than a log search | ADR-13 |
| Audit | Append-only audit table with a Cloud Storage Object Lock export, 7 years | Google Cloud | S3 Object Lock; Azure immutable blob storage; an on-prem WORM appliance | The acts worth auditing are the ones that multiply work, and their record has to survive the actor who performed them | ADR-15 |
When a dispatcher dies holding a fire it has decided is due, what has been lost?
If the API that creates schedules is down, should schedules still fire?
Two schedulers both believe the same instant is due. What stops two fires?
A node believes it is 09:00:00. How wrong could it be, and which direction of wrongness is acceptable?
Should the next thousand fire instants be computed now and stored, or computed each time they are needed?
What does "every day at 02:30" mean on the day 02:30 happens twice, and on the day it does not happen at all?
Who decides what a trigger does about the fires it missed, and when is that decision taken?
A trigger is resumed after a month. How much work does it owe?
A backlog is released. What stops its drain from being the next outage?
The previous execution has not reported back. Is it still running?
Sixty per cent of all fires land in the first second of a minute. Do we buy capacity for that second?
The due index is corrupt. Do we restore it, or recompute it?
How does anyone find out that the scheduler has stopped firing?
What stops a schedule from being a timer-driven request forgery primitive aimed at someone else?
Should the person who can create a schedule also be able to make it emit a month of work?
The scheduler carries an opaque blob it never interprets. Where is that blob allowed to exist?
These terms are used precisely in this package. Several are used loosely in the wider literature on schedulers and cron services, and the difference matters when reading the decision records.
| Package | What it is | What it does here | Considered instead |
|---|---|---|---|
| Scheduled instant | The absolute UTC instant a recurrence resolves to, derived from the expression, the named zone and a recorded time-zone database version. | The thing the fire is identified by, ordered by, and measured against. | "Fire time", which is usually used for the moment a dispatch actually left — the quantity this package calls the dispatch instant. |
| Fire record | An immutable row committed before any dispatch attempt, carrying the tenant, trigger, definition version, scheduled instant and a deterministic key. | The scheduler's durable product and the system of record for "was this instant decided". | A "job run", which implies work happened; a fire record says only that a decision was taken. |
| Idempotency key | The fire's four-part primary key (tenant, trigger, scheduled instant, sequence), computed rather than generated. | Makes a duplicate decision a uniqueness violation instead of something to detect, and gives the executor something to deduplicate on. | A generated request identifier, which deduplicates transport retries but cannot deduplicate two independent decisions. |
| ε (clock uncertainty) | The half-width of the interval a bounded time source reports around the current instant. | The quantity the scheduler waits out, which is what converts clock skew into lateness rather than earliness. | "Clock skew", which usually names the error itself rather than a reported bound on it. |
| Lateness | Dispatch instant minus scheduled instant, measured per fire and published per trigger as a distribution. | The budget the design spends; it is the measure of availability for the dispatch plane. | "Latency", which in a request-shaped service means time to respond rather than distance from a deadline. |
| Missed-fire policy | A per-trigger declaration — fire-all, fire-once-now or skip — of what to do with instants that should have fired and did not. | Moves the post-outage decision from the incident to the definition. | "Misfire instruction" in some scheduler libraries, usually with the same three options and no horizon. |
| Catch-up horizon | The maximum age of a missed instant that may still be dispatched; beyond it the instant is recorded as expired. | The platform's bound on how much work any interruption can accumulate, overriding the tenant's policy. | A "grace period", which usually means how long a late fire is still considered on time. |
| Catch-up storm | A backlog of missed instants released at once by a recovery, a resume or a backfill. | The expected failure mode of a scheduler, and the thing the lane split and the rate cap exist for. | A "thundering herd", which names simultaneous arrival generally rather than the self-inflicted recovery case. |
| Overlap policy | A per-trigger declaration — allow, skip or queue — of what to do when a fire comes due while the previous execution has not reported terminal. | The only control the scheduler has over concurrency in work it does not run. | "Concurrency policy", which in some systems bounds parallel runs numerically rather than deciding what to do about one. |
| Unknown (terminal state) | The recorded state of a fire whose outcome never arrived inside its outcome window, including a dispatch attempt that timed out. | Prevents the scheduler withholding every later fire on a missing callback, at the price of occasional concurrent execution. | "Failed", which asserts the work did not happen — a claim the platform cannot make about a timeout. |
| Backfill | An authorised generation of fires for a declared past window, labelled as such and rate-capped in its own lane. | The recovery path for work lost beyond the horizon, and a privilege separate from authorship. | A "replay", which in event systems means re-delivering records that already exist rather than creating new ones. |
| Partition lease | A short-TTL claim on a range of the trigger keyspace, recording the ε observed at grant. | The unit of mutual exclusion in the timing plane — deliberately imperfect, because the fire key makes imperfection survivable. | "Leader election", which implies one authority per service rather than one per partition. |
| Due index | One row per live trigger holding its single next instant, partitioned and scanned in time order. | The structure the scheduler reads; a rebuildable projection of the registry, not a system of record. | A "timer wheel", which is an in-memory structure with the same purpose and no durability. |
| Oldest undispatched due age | The age of the oldest instant that is due and has not yet been dispatched, measured per partition. | The paging alert, because it is the only signal that distinguishes a healthy scheduler from a silent one. | "Queue depth", which counts work waiting without saying how long the oldest item has been waiting. |
svg/<view>.svg or drawio/<view>.drawio in draw.io Desktop or at app.diagrams.net to edit. The SVG carries the diagram inside it, so it is both the picture and the source. This folder is self-contained — copy it whole and every link still resolves.