Integrations · Phased project

Evolve a notification boundary with predictable failure behavior

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.

Practice brief · Version 5

Project scope: 10 tickets / 3 phases
Total focused work estimate: 29h + setup
Suggested stack: TypeScript · Node.js · Vitest · Local HTTP stubs

Recommended next step

Start with PPROVIDER-101

Open the first ticket for its prerequisites, acceptance criteria, verification plan, and an editable task draft.

Open first ticket Add to My work

What the engineer takes away

Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults.

What the team gains

Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion.

Before you start

HTTP contracts
Asynchronous cancellation
Dependency injection

Delivery agreement

Ten tickets over three phases. Create local provider doubles and contract fixtures, evolve the integration layer, and supply a fault replay plus an operational handoff.

AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior.

Delivery phases

PHASE 1
Define the provider boundary
Separate scheduling intentions from transport details.
PHASE 2
Compose cross-cutting behavior
Keep orchestration and wrapper ordering visible and testable.
PHASE 3
Contain provider failure
Bound outstanding work and verify recovery without duplicate delivery.

Define the provider boundary

Separate scheduling intentions from transport details.

PPROVIDER-101
Normalize the second provider's acknowledgement without inventing delivery
Entry ticket; project setup still required
Estimated field mix
- Integrations70%
- API design30%
Pattern topics
- AdapterApply
Story · Foundational · 2hAdd to My work
PPROVIDER-102
Keep provider SDK types out of appointment rules
Depends on PPROVIDER-101
Estimated field mix
- Integrations50%
- System design50%
Pattern topics
- Ports and AdaptersApply
Chore · Intermediate · 2h 30mAdd to My work
PPROVIDER-103
Validate notice inputs before choosing a provider
Depends on PPROVIDER-102
Estimated field mix
- Integrations60%
- Privacy engineering40%
Pattern topics
- Chain of ResponsibilityCompare
Bug · Foundational · 1h 30mAdd to My work

Compose cross-cutting behavior

Keep orchestration and wrapper ordering visible and testable.

PPROVIDER-104
Decouple notice format from the selected transport
Depends on PPROVIDER-102, PPROVIDER-103
Estimated field mix
- Integrations50%
- System design50%
Pattern topics
- BridgeCompare
Story · Advanced · 3hAdd to My work
PPROVIDER-105
Record one bounded telemetry event around each provider attempt
Depends on PPROVIDER-102
Estimated field mix
- Integrations40%
- Site reliability30%
- Privacy engineering30%
Pattern topics
- DecoratorApply
Story · Intermediate · 2h 30mAdd to My work
PPROVIDER-106
Replace the scheduler's six-call notification sequence with one bounded operation
Depends on PPROVIDER-103, PPROVIDER-104, PPROVIDER-105
Estimated field mix
- Integrations50%
- Backend30%
- System design20%
Pattern topics
- FacadeApply
Chore · Advanced · 3hAdd to My work
PPROVIDER-107
Remove the transparent send proxy that retries an ambiguous timeout
Depends on PPROVIDER-106
Estimated field mix
- Integrations50%
- Distributed systems50%
Pattern topics
- ProxyRemove
Bug · Advanced · 3h 30mAdd to My work

Contain provider failure

Bound outstanding work and verify recovery without duplicate delivery.

PPROVIDER-108
Pause a failing provider and admit one recovery probe
Depends on PPROVIDER-105, PPROVIDER-107
Estimated field mix
- Site reliability50%
- Integrations30%
- Distributed systems20%
Pattern topics
- Circuit BreakerApply
Story · Advanced · 3h 30mAdd to My work
PPROVIDER-109
Keep one slow provider from occupying every notification slot
Depends on PPROVIDER-107
Estimated field mix
- Performance engineering40%
- Site reliability40%
- Integrations20%
Pattern topics
- BulkheadApply
Story · Advanced · 3h 30mAdd to My work
PPROVIDER-110
Prove wrapper order preserves deadlines, probe limits, and attempt counts
Depends on PPROVIDER-108, PPROVIDER-109
Estimated field mix
- System design40%
- Site reliability30%
- Integrations30%
Pattern topics
Task · Expert · 4hAdd to My work