Design the preference service every notification in a collaboration suite must consult before it goes out: given a user and an event (a mention, a comment reply, a task assignment), it answers "should we notify this person, and on which channels?" It is the single arbiter of email vs push vs in-app, quiet hours, per-category mutes, and digest-vs-instant.

Operating context. Every notification-producing system calls this service on its critical path, so it is read-dominated and extremely latency-sensitive. Preferences form a hierarchy: sensible product defaults, overridden by workspace/org policy, overridden by the individual user's choices. Users flip settings from a UI and expect the change to take hold almost at once. Because the service gates all notifications, its own outage is dangerous — it must fail safe rather than silently drop or spam.

Out of scope. The notification content templating and rendering, the actual delivery transport for each channel, event generation and aggregation, and analytics on notification engagement. Assume callers hand you a typed event and a user identity and want a routing decision back.

What to produce. A high-level architecture covering: the preference data model (category by channel, quiet hours, digest, and the override hierarchy); the evaluation engine that resolves precedence into a decision; the low-latency serving path with caching and replication; how a preference edit propagates to evaluators; and the fail-safe behavior when the service or its store is degraded. Sketch the components and the flow of one "should I notify?" call; we will probe specifics in checkpoints.