Design a **microservice that accepts notifications**, can handle sudden bursts of large data volume, and provides low latency.
Clarify what a notification contains, who sends it, and what must happen after acceptance. In particular, distinguish the latency of accepting a notification from the latency of processing it or delivering it onward. No specific throughput, burst duration, broker, destination channel, or numeric latency target is given; propose and justify the choices needed for your design.
Explain the request path, buffering and processing, overload behavior, failure recovery, and how you would evaluate whether the service meets the agreed latency and burst requirements.
### What a Strong Answer Covers
- An explicit acceptance guarantee and the durable state behind it.
- How the service absorbs a burst and what happens when buffering or processing capacity is exhausted.
- Retry and duplicate behavior when a response is lost or a worker fails.
- The tradeoffs among batch size, queue delay, ordering, and processing throughput.
- Measurements that separate fast acknowledgment from timely completion.
### Follow-up Questions
- What changes if arrivals remain above processing capacity instead of forming a short burst?
- How does a producer determine what happened after it times out waiting for an acknowledgment?
Overview: Design a low-latency notification microservice for traffic bursts, balancing durable acceptance, buffering, retries, overload control, and completion time.
Design a microservice that accepts notifications, can handle sudden bursts of large data volume, and provides low latency.
Clarify what a notification contains, who sends it, and what must happen after acceptance. In particular, distinguish the latency of accepting a notification from the latency of processing it or delivering it onward. No specific throughput, burst duration, broker, destination channel, or numeric latency target is given; propose and justify the choices needed for your design.
Explain the request path, buffering and processing, overload behavior, failure recovery, and how you would evaluate whether the service meets the agreed latency and burst requirements.
What a Strong Answer Covers Guidance
An explicit acceptance guarantee and the durable state behind it.
How the service absorbs a burst and what happens when buffering or processing capacity is exhausted.
Retry and duplicate behavior when a response is lost or a worker fails.
The tradeoffs among batch size, queue delay, ordering, and processing throughput.
Measurements that separate fast acknowledgment from timely completion.
Follow-up Questions Guidance
What changes if arrivals remain above processing capacity instead of forming a short burst?
How does a producer determine what happened after it times out waiting for an acknowledgment?