Compare Scenarios

Migration Step 1

Both scenarios define a migration step at this stage. Notification Delivery Platform: triggered by 'Notification provider latency (SendGrid, FCM) adding 200–500'. Analytics Data Platform: triggered by 'OLTP query p99 degrading during analytics reporting windows;'.

Migration Step 2

Both scenarios define a migration step at this stage. Notification Delivery Platform: triggered by 'Product requirement to add mobile push notifications and SMS'. Analytics Data Platform: triggered by 'Sub-minute analytics freshness SLA required; ETL scheduling '.

Migration Step 3

Both scenarios define a migration step at this stage. Notification Delivery Platform: triggered by 'User complaints about notification volume increasing; spam c'. Analytics Data Platform: triggered by 'Dashboard query p95 > 5s on frequently accessed aggregation '.

RabbitMQ queue depth for email channel growing > 100k messages; SendGrid 429 responses visible in delivery worker logs; email delivery p95 latency > 2 minutes; delivery worker retry thread pool saturated; dead-letter queue receiving messages from retry exhaustion despite provider being available

Tier 1: Provider Rate Limit Backlog: Delivery worker retry policy not aligned with provider rate limit reset window; workers retrying before the rate limit has reset, accumulating failed attempts. Recommended evolution: Implement provider-aware retry backoff: on 429 response, parse the Retry-After header and schedule the next retry attempt at exactly that time, not on a fixed exponential backoff schedule; add per-provider circuit breakers that open after 5 consecutive 429s and attempt a probe request at the retry-after interval; scale email consumer replicas to process the backlog faster when the rate limit window resets .

Kafka consumer lag for notification event consumers growing; notification delivery volume much higher than upstream business event volume (ratio > 5:1); RabbitMQ aggregate message rate across all channel queues elevated; one upstream event type (e.g., new_comment) accounting for disproportionate share of notification volume

Tier 2: Notification Fan-Out Amplification: Upstream event fan-out generating more notification sends per event than expected; or a notification rule misconfiguration triggering notifications for every event regardless of user preference. Recommended evolution: Audit notification fan-out ratio per upstream event type; add fan-out cost metrics (notifications_generated per upstream event) as a monitored SLA; implement notification preference filtering before fan-out: only generate delivery attempts for users with the corresponding notification type enabled; implement a notification aggregation layer that batches multiple low-priority events into digest notifications rather than individual sends .

Kafka consumer group lag (bytes or offsets) growing for the analytics topic group; ClickHouse dashboard timestamps falling behind wall clock by > 60s; ClickHouse insert throughput < Kafka produce rate

Tier 1: Consumer Lag and Freshness Degradation: ClickHouse insert throughput insufficient for Kafka produce rate. Recommended evolution: Tune ClickHouse insert buffer size and async_insert settings; increase consumer parallelism up to the Kafka partition count; batch inserts into ClickHouse using the Buffer engine or materialized views with merge trees .

One Kafka partition offset growing significantly faster than others; one consumer instance CPU/network saturated while others are idle

Tier 2: Hot Partition and Skewed Consumer Load: Skewed partition key distribution: high-cardinality entity routing the same high-volume key to one partition. Recommended evolution: Add a secondary hash suffix to the partition key to distribute load; increase topic partition count (note: keyed ordering breaks for existing messages); re-evaluate partition key selection based on actual cardinality measurements .