ORIGINAL TECHNICAL PRACTICE
Start a design with workload and SLOs
Before designing a notification service, what requirements and capacity estimates would you establish?
Written for independent practice. The model answer presents one approach; clarify constraints and explain alternatives.
A REASONED APPROACH
Model answer.
Clarify the user-visible contract and expected workload before choosing components. A useful design separates submission acknowledgement, delivery attempts and confirmed receipt, because they have different latency and reliability meanings.
Work through it
- Estimate average and peak submissions, recipients per notification, payload size, channel mix and retention. Identify burst sources and growth assumptions rather than presenting one unsupported traffic number.
- Define availability and latency objectives for submission and delivery, plus ordering, deduplication and expiry requirements. Establish what delivery providers actually guarantee.
- Sketch the simplest architecture meeting those requirements and estimate queue depth, storage and worker throughput. Explain overload behavior and how to measure the objectives.
Tradeoffs to discuss
- A durable asynchronous queue absorbs bursts but introduces delivery delay and operational work. Synchronous delivery is simpler but couples the caller to provider latency and outages.
Common pitfalls
- An API returning200 does not prove a recipient received a message. Average traffic alone hides the peak that usually drives capacity and backpressure requirements.