Compare Scenarios

Migration Step 1

Both scenarios define a migration step at this stage. Write-Heavy Transactional Platform: triggered by 'Dual-write inconsistency events observed in production: DB w'. 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. Write-Heavy Transactional Platform: triggered by 'Primary write CPU > 70% sustained during peak windows; WAL v'. ML Feature Serving Platform: triggered by 'Regulatory or reproducibility requirement to re-run model pr'.

Migration Step 3

Both scenarios define a migration step at this stage. Write-Heavy Transactional Platform: triggered by 'Audit completeness requirements grow beyond point-in-time ba'. ML Feature Serving Platform: triggered by 'Semantic similarity search recall insufficient from BM25 ful'.

PgBouncer wait_queue > 0 sustained; application p99 write latency rising faster than PostgreSQL p99; pool_mode=transaction showing >80% utilization

Tier 1: Connection Pool Saturation: PgBouncer pool_size too small for write concurrency profile. Recommended evolution: Increase PgBouncer pool_size incrementally; profile transaction duration to right-size pool; consider separate pools for write-heavy and read-only workloads .

PostgreSQL checkpoint_completion_target warnings in logs; wal_buffers flushing more than once per second; pg_stat_bgwriter shows checkpoints_req rising; write p99 > 20ms without query explanation

Tier 2: WAL and Checkpoint Pressure: Write rate exceeding PostgreSQL's WAL flush and checkpoint throughput. Recommended evolution: Tune checkpoint_completion_target to 0.9; increase wal_buffers to 64MB; move PostgreSQL WAL to a dedicated NVMe volume separate from data directory .

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. .