DBRaven

Notification Delivery Platform

Event-Driven Systemmoderate complexity

Deterministic topology derived from YAML knowledge entities. Nodes represent workloads, datastores, patterns, and risk components. Edges show typed relationships with propagation direction.

17

Components

0

Connections

5

Failure Modes

1

Propagation Paths

Max exposure: high· 2 high-risk nodes in this topology
Topology Graph17 nodes · 0 edges
2 high-risk nodesClick a failure mode below to trace propagation
Workload
Datastore
Cache
Event stream
Pattern
Risk node
Risk path

Failure Propagation Trace

Topology Notes

  • ·The Kafka consumer (notification router) reads upstream business events and applies three sequential decisions before publishing to RabbitMQ: (1) check inbox table for idempotency: is this event_id already processed? (2) apply notification rules : does this event type generate notifications, and for which recipients? (3) apply user preferences and rate limiting: is this user's quota available, and do they have this notification type enabled? Only messages passing all three checks are published to the RabbitMQ channel exchange.
  • ·RabbitMQ exchanges are topic exchanges with routing keys of the form channel.priority (e.g., "email.critical", "push.marketing"). Each channel has two queues: a priority queue (circuit-breaker-protected, monitored for delivery SLA) and a standard queue (best-effort, rate-limited). The routing key format is the single configuration point for adding new channels or priority tiers.
  • ·PostgreSQL stores the notification audit trail: every notification_id with its event_source_id, recipient_id, channel, priority, delivery_state, and delivery timestamps. This table is the source of truth for delivery audits and the basis for deduplication via the inbox pattern. It is never queried for real-time delivery decisions: Redis is the performance path for deduplication token checks.
  • ·Redis serves two distinct functions: (1) deduplication token store: keys are notification_id hashes with TTL matching the expected upstream event replay window (default 24h); (2) per-user rate limit counters: sliding window counters keyed by user_id + channel + notification_tier with TTL matching the rate limit window. These two data sets have different access patterns and TTLs: they should be separate Redis key prefixes or namespaces for independent TTL management.
  • ·Circuit breakers are implemented per-provider (not per-channel) in the delivery workers. A SendGrid circuit breaker opening does not affect FCM or Twilio delivery. Circuit breaker state is stored in Redis (not local worker memory) so that all delivery worker replicas share the same breaker state: a provider outage detected by one worker immediately stops all workers from attempting that provider.