Sample output
Made on 27 October 2026
Estimation scale
- S: 0.5–1.5 engineering days
- M: 2–3 engineering days
- L: 4–5 engineering days
Assumes one engineer, code review included, existing CI/CD and authentication, and no major infrastructure procurement. QA/UAT time is included per slice but cross-system rollout support is not.
Delivery slices
1. Notification event contract and channel-agnostic model — M
Scope
- Define notification types, recipients, payload schema, priority, channel eligibility, timestamps, and idempotency key.
- Add producer-facing API or internal library.
- Persist notification requests and processing state.
Assumptions
- Initial notification catalog is known or can be limited to a small representative set.
- Existing services can publish events or call an internal API.
- At-least-once processing is acceptable.
Key unknown
- How consistently existing producers identify users and emit actionable events.
30-minute spike
- Inspect three representative producers and trace their current event payloads, user IDs, and retry behavior.
Size: M
- The schema and storage are straightforward, but compatibility and idempotency require care.
2. Dispatch queue and worker foundation — M
Scope
- Route persisted notification requests to asynchronous workers.
- Implement retry policy, dead-letter handling, idempotency, and basic delivery state transitions.
- Add worker health metrics.
Assumptions
- A managed queue, stream, or job system already exists.
- Ordering is not required across unrelated notifications.
- Exact-once delivery is not required.
Key unknown
- Whether the existing queue supports delayed retries, dead-lettering, and sufficient throughput.
30-minute spike
- Review queue configuration and run a small publish/consume/retry test in a non-production environment.
Size: M
- Existing infrastructure keeps the work bounded; custom queue infrastructure would make this L.