eho/register-referentie
1
0
Fork 0
Code Issues 10 Pull Requests 1 Actions Packages Projects Releases 1 Wiki Activity

ADR: Quartz.NET for time-triggered fleet sweeps (herregistratie reminder), pumps stay #120

New Issue
Closed
opened 2026-07-23 09:46:24 +00:00 by not · 0 comments
not commented 2026-07-23 09:46:24 +00:00
Contributor
Copy Link
Copy Source

Raised while picking up S-17 (#18). Adding Quartz.NET is a new dependency → ADR-worthy (CLAUDE.md §14). Filing before coding.

Decision to be made: How does the Domain Service run the herregistratie reminder sweep — and periodic fleet-wide sweeps generally?

Context / forces: The service already runs periodic work as BackgroundService "pump" loops (OpenZaakJobPump, BeoordelingEscalatiePump, RegistratieVerlopenPump). Those are continuous job pollers draining Flowable's external-task/job queues at-least-once — event-driven, pick-up-ASAP work. The herregistratie reminder is a different shape: a time-triggered, once-a-day sweep of inscriptions approaching their validity end. PRD §39/§94 already name Quartz.NET as the scheduler for "fleet-wide sweeps (expiry, reminders)".

Options considered:

  1. Reuse a BackgroundService with a 24h Task.Delay. No new dependency, smallest diff — but drifts to process-start time, no cron/misfire semantics, and contradicts the PRD's named component.
  2. Add Quartz.NET for the sweep; leave the pumps as-is.
  3. Add Quartz.NET AND migrate the three pumps onto it for one scheduling mechanism.

Proposed option + why: Option 2. The sweep is a genuine cron concern (Quartz gives cron expressions + misfire handling + restart-stable timing) and the PRD commits to Quartz here. Reject option 3: the pumps aren't schedulers — forcing a "run at time T" tool onto "drain this queue continuously" is churn and a boundary change for negative benefit. The teachable distinction stays: pumps drain queues; Quartz fires sweeps.

Consequences: One new dependency (Quartz + Quartz.Extensions.Hosting) in the Domain Service. A cron-scheduled hosted job. Two deliberately distinct scheduling patterns coexist, documented in the ADR. Reminder cadence/validity become calibration knobs.

Coupling rules touched (CLAUDE.md §8): None. Quartz is internal to the Domain Service; it drives an Application use case over the store port. No ZGW/Flowable coupling added.

On acceptance, docs/architecture/adr-0022-*.md lands in the S-17 PR.

Raised while picking up S-17 (#18). Adding Quartz.NET is a new dependency → ADR-worthy (CLAUDE.md §14). Filing before coding. **Decision to be made:** How does the Domain Service run the herregistratie reminder sweep — and periodic fleet-wide sweeps generally? **Context / forces:** The service already runs periodic work as `BackgroundService` "pump" loops (`OpenZaakJobPump`, `BeoordelingEscalatiePump`, `RegistratieVerlopenPump`). Those are **continuous job pollers** draining Flowable's external-task/job queues at-least-once — event-driven, pick-up-ASAP work. The herregistratie reminder is a different shape: a **time-triggered, once-a-day sweep** of inscriptions approaching their validity end. PRD §39/§94 already name **Quartz.NET** as the scheduler for "fleet-wide sweeps (expiry, reminders)". **Options considered:** 1. Reuse a `BackgroundService` with a 24h `Task.Delay`. No new dependency, smallest diff — but drifts to process-start time, no cron/misfire semantics, and contradicts the PRD's named component. 2. Add Quartz.NET for the sweep; leave the pumps as-is. 3. Add Quartz.NET AND migrate the three pumps onto it for one scheduling mechanism. **Proposed option + why:** **Option 2.** The sweep is a genuine cron concern (Quartz gives cron expressions + misfire handling + restart-stable timing) and the PRD commits to Quartz here. Reject option 3: the pumps aren't schedulers — forcing a "run at time T" tool onto "drain this queue continuously" is churn and a boundary change for negative benefit. The teachable distinction stays: **pumps drain queues; Quartz fires sweeps.** **Consequences:** One new dependency (`Quartz` + `Quartz.Extensions.Hosting`) in the Domain Service. A cron-scheduled hosted job. Two deliberately distinct scheduling patterns coexist, documented in the ADR. Reminder cadence/validity become calibration knobs. **Coupling rules touched (CLAUDE.md §8):** None. Quartz is internal to the Domain Service; it drives an Application use case over the store port. No ZGW/Flowable coupling added. On acceptance, `docs/architecture/adr-0022-*.md` lands in the S-17 PR.
not added this to the Iteration 3 — Beheer & Observability milestone 2026-07-23 09:46:24 +00:00
not added the type:adr-proposalarea:domainarea:infra labels 2026-07-23 09:46:31 +00:00
not closed this issue 2026-07-23 10:31:58 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area:acl
area:bff
area:docs
area:domain
area:event-subscriber
area:infra
area:portal-behandel
area:portal-beheer
area:portal-openbaar
area:portal-self-service
area:projection
area:workflow
type:adr-proposal
type:bug
type:chore
type:slice
No labels area:domain area:infra type:adr-proposal
Milestone
No items
No Milestone Iteration 3 — Beheer & Observability
Projects
Clear projects
No projects
Assignees
Clear assignees
eho (Edwin van den Houdt)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: eho/register-referentie#120