Replace the scheduler's six-call notification sequence with one bounded operation
Every scheduling handler must validate, format, select an adapter, initialize telemetry, call send, and map the result in the right order. One handler skips validation and another catches all failures as accepted.
- Focused work estimate
- 3h + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Application boundaries · Error propagation · Orchestration testing
Estimated field mix
- Integrations50%
- Backend30%
- System design20%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Pattern topics
- FacadeApply
Offer scheduling callers one explicit notification operation while preserving distinct validation, content, and transport responsibilities underneath.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional maintenance scheduler sends appointment notices through two providers. Their request shapes, error codes, and acknowledgement semantics differ. Build two local scripted provider doubles and a TypeScript application module; use synthetic recipients, block external network access, and never send real notifications. No provider accounts, starter repository, or production delivery qualification is supplied.
Setup prerequisites
- HTTP contracts
- Asynchronous cancellation
- Dependency injection
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- PPROVIDER-101 · Normalize the second provider's acknowledgement without inventing delivery
- PPROVIDER-102 · Keep provider SDK types out of appointment rules
- PPROVIDER-103 · Validate notice inputs before choosing a provider
- PPROVIDER-104 · Decouple notice format from the selected transport
- PPROVIDER-105 · Record one bounded telemetry event around each provider attempt
Acceptance criteria
- Expose one application operation that coordinates the declared preflight, content, adapter, and result steps.
- Return typed accepted, rejected, and unknown outcomes without concealing which stage failed.
- Keep policy and transport modules independently testable; the Facade must not absorb appointment rules, template storage, or unrelated administration.
Implementation constraints
- This operation makes at most one provider attempt. Automatic failover and retries are excluded until duplicate-acceptance behavior is defined.
Verification to include
- Call the operation from reminder and cancellation flows and compare stage order and result handling.
- Fail every stage in turn and assert later side effects do not run; preserve an unknown outcome after ambiguous transport completion.
Deliverables
- Notification Facade and stage-failure test matrix
Rollout and recovery
Move the two local scheduling handlers behind the operation with parity fixtures; revert one caller only if its behavior remains explicit.
Value of the work
For the engineer: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults.
For the team: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.