Design a Notification System, stage 5 of 11: model
Trace a mention to a phone
Alice mentions Bob in a comment. Put the steps from her click to the push notification on Bob's phone in order.
System so far· 4 parts
Select a component to see what it is responsible for and which state it owns.
- 1Product services → Event stream: Domain events via outbox
- 2Event stream → Notification planner: Events, at least once
- 3Notification planner → Notifications DB: Insert notifications under dedupe keys
- Asynchronous
- Request / response
What you need to know
A pipeline that crosses several services stays reliable when every hop follows the same rhythm: record durably, act, record the outcome. Each record lets the next step be retried without redoing or losing work.
When tracing a request, look for where the user's part ends. Everything after that can be slow or retried without them seeing it.
Check
When can Alice's comment request return?Push providers (APNs, FCM) report a device token as invalid when the app has been uninstalled or the token has rotated. Sending to it again will fail every time.
A sender that removes tokens as soon as a provider rejects them keeps each user's device list accurate without a separate cleanup job.
Think first
Bob's inbox shows the mention even though the push to his phone failed. Why is that possible?