Compare Scenarios

Migration Step 1

Both scenarios define a migration step at this stage. Read-Heavy SaaS API: triggered by 'Connection pool exhaustion or p99 read latency > 200ms under'. 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. Read-Heavy SaaS API: triggered by 'Primary CPU > 70% during peak read hours'. 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; Read-Heavy SaaS API does not at this stage.

p99 database latency rising; connection wait queue growing; requests timing out with "too many connections" or pool queue full errors

Tier 1: Connection Exhaustion: Database connection pool saturated or max_connections exceeded. Recommended evolution: Add PgBouncer connection pooler in transaction mode.

Database CPU > 80% sustained; read query p99 rising; cache miss rate stable but overall latency increasing

Tier 2: Read Throughput Ceiling: Single PostgreSQL primary saturated with read traffic. Recommended evolution: Add one or more streaming read replicas; implement lag-aware replica routing.

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