Compare Scenarios

Migration Step 1

Both scenarios define a migration step at this stage. Event-Driven Analytics Pipeline: triggered by 'OLTP query performance degrading due to analytics query inte'. ML Feature Serving Platform: triggered by 'Feature computation logic duplicated across 3+ model serving'.

Migration Step 2

Both scenarios define a migration step at this stage. Event-Driven Analytics Pipeline: triggered by 'Sub-minute analytics latency required; ETL scheduling overhe'. ML Feature Serving Platform: triggered by 'Regulatory or reproducibility requirement to re-run model pr'.

Migration Step 3

ML Feature Serving Platform has a defined migration; Event-Driven Analytics Pipeline does not at this stage.

pg_replication_slots shows growing pg_wal_lsn delta for CDC slot; PostgreSQL WAL directory growing faster than expected

Tier 1: CDC Slot Lag: Debezium / CDC connector not keeping up with write volume. Recommended evolution: Increase CDC connector parallelism; review filtered topics vs full-table CDC; monitor slot lag as a first-class SLA .

Kafka consumer group lag growing; analytics dashboards increasingly stale; consumer CPU and network I/O near ceiling

Tier 2: Kafka Consumer Lag: Insufficient consumer parallelism or insufficient Kafka partitions. Recommended evolution: Increase topic partition count (note: keyed messages lose ordering when partitions added); add consumer replicas up to partition count .

Feature store p99 rising from < 5ms to > 50ms immediately following a model deployment or pod scaling event; Cassandra or PostgreSQL feature store read QPS spiking 10–100x simultaneously with serving fleet restart; feature store connection pool exhaustion visible in application logs during the cold start window; Redis cache hit rate dropping to < 10% for the first 60 seconds after deployment

Tier 1: Cache Cold Start Latency Spike: Simultaneous cache cold start across all serving pods after deployment, converting sequential feature requests into a thundering herd against the backing feature store. Recommended evolution: Implement pre-warming: before a new model version receives traffic, a warm-up job runs inference requests for a representative sample of entity IDs, populating the Redis cache before the pod enters the serving fleet. Use probabilistic early cache refresh (fetch from backing store before TTL expiry when remaining TTL < 20% under high request rate) to prevent simultaneous TTL expiry on hot features. Stagger deployment rollout: deploy 10% of pods, wait for cache warm, then proceed to the next 10%. .

Model performance metrics (precision, recall, AUC) degrading without a corresponding input distribution shift; ClickHouse drift dashboard showing feature value distributions served online diverging from training population distributions; explicit skew audit (comparing offline training feature values against replayed online feature values for the same entity at the same timestamp) showing systematic differences in specific features

Tier 2: Training-Serving Skew Detection: Feature computation logic divergence between the offline training pipeline and the online serving pipeline: a feature transformation applied in training is not applied identically in serving. Recommended evolution: Enforce a single feature computation function registered per feature in a shared feature registry, executed by both the online pipeline and the offline training pipeline. The two paths must use the same code, not independently maintained implementations. Implement a skew monitoring job that computes a random sample of features using both paths and alerts on distribution divergence above a threshold. .