Scalable Notification Center
Design the frontend architecture for a notification center that can grow beyond one component without turning state into duplicated, tightly coupled data.
Product requirements
The provided API accepts marking n-1 as read and rejects n-2, giving you deterministic success and rollback paths without replacing the API.
- Load notifications through the provided asynchronous API and cancel obsolete work during cleanup.
- Keep remote notifications as the source of truth; derive the unread count and filtered list.
- Support All and Unread views without storing a second notification collection.
- Mark a notification as read optimistically and roll back when persistence fails.
- Show loading, empty, and error states.
- Keep list keys stable.
- Separate data orchestration from presentation so another screen could reuse the notification state.
Architecture constraints
- You may reorganize responsibilities inside the provided workspace files.
- Do not place every state transition and every row of markup in
App.tsx.
- Do not introduce a second copy of notification server state.
- Avoid effects that merely synchronize one state value with another.
- Keep public context or hook types explicit.
Recommended checks
Use Run checks to exercise loading, filtering, and optimistic updates. Verify & submit runs the required browser checks on the verification service; they must pass to complete the day. AI architecture review is separate feedback.
Interview review
After submitting, consider how you would explain:
- Which state belongs in the provider and which state should remain local?
- When would you replace this provider with a server-state library?
- How would pagination, real-time events, and request deduplication change the design?
- Where would you add error reporting and performance measurements in production?