Project · Advanced · about 28 hours
Build the notification service from the design
Implement a notification service with idempotent requests, per-priority queues, provider rate limits, retries, fallbacks and a dead-letter queue, driven by real order events.
Skills:Kafka and event streaming, Microservices, Monitoring and observability, System design
Part of: Software Engineer (Backend)
Data and licences
- Olist Brazilian E-Commerce Public Dataset (Kaggle) ↗CC BY-NC-SA 4.0 (non-commercial use, share alike)
Brief
The notification system design walkthrough on the System design shelf describes the architecture. Build it. Olist order events (placed, shipped, delivered, reviewed) are replayed to trigger transactional notifications, while a marketing campaign to all customers runs at the same time.
What to build
POST /notificationswith idempotency keys, preferences per category and channel, and templates.A router that fans out per channel onto priority queues (Kafka topics or another broker).
Channel workers with provider rate limits, timeouts, retries with backoff and jitter, circuit breakers and a dead-letter queue.
Mock providers you can make slow or fail, and callbacks for delivered and bounced messages.
Scenarios: replay 50,000 order events while a campaign to 100,000 customers runs; take the SMS provider down for five minutes; restart workers mid-run.
Deliverables
Repository with
api/,router/,workers/,providers-mock/,scenarios/, dashboards andREPORT.md
How it is graded
Reviewers run the scenarios and check three numbers: duplicates (should be zero), transactional delivery latency during the campaign, and messages lost (should be zero, with failures in the DLQ).
Stretch
Add a digest mode that batches low-priority notifications into one daily email per user.
Deliverables
- A notification API with idempotency keys, user preferences and templates
- Separate queues for transactional and marketing messages, with workers per channel and provider rate limits
- Mock push, email and SMS providers with configurable latency and failure rates
- A test report showing no duplicates, fast transactional delivery during a campaign, and correct handling of provider outages
How a reviewer grades it
| Criterion | Weight | What good looks like |
|---|---|---|
| No lost or duplicate notifications under retries and restarts | 30% | |
| Transactional messages stay fast while a large campaign runs | 25% | |
| Provider failures are handled with backoff, circuit breakers, fallbacks and a DLQ | 25% | |
| Metrics and alerts for queue age, error rates and DLQ size | 20% |