Compare Scenarios

Migration Step 1

Both scenarios define a migration step at this stage. Streaming Media Platform: triggered by 'Upload API p99 exceeding 30 seconds due to in-process transc'. 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. Streaming Media Platform: triggered by 'PostgreSQL viewing history table exceeding 500M rows; write '. 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. Streaming Media Platform: triggered by 'CDN provider incident causing total origin failover; CDN mis'. ML Feature Serving Platform: triggered by 'Semantic similarity search recall insufficient from BM25 ful'.

Kafka consumer group lag on the transcoding topic growing during peak upload hours; content availability delay > 10 minutes for newly uploaded videos; transcoding worker CPU consistently above 85% across all instances

Tier 1: Transcoding Worker Throughput: Transcoding consumer group undersized relative to peak upload volume. Recommended evolution: Increase transcoding consumer instances up to the transcoding topic partition count; tune partition count to match the maximum desired worker parallelism (set this at topic creation, not after lag appears); implement per-uploader upload rate limits to smooth burst input; consider priority queuing so premium-tier content does not wait behind bulk ingest jobs .

MinIO GET request rate spikes > 10x baseline immediately after content publish or CDN invalidation; MinIO p99 latency > 500ms; CDN miss ratio > 5% on popular content

Tier 2: CDN Origin Thundering Herd: CDN cache miss storm on first-play of new or recently-updated content. Recommended evolution: Implement origin request coalescing (single origin fetch per CDN node per object, queue subsequent requestors for the in-flight response); pre-warm CDN edges for anticipated high-traffic content before publish; add rate limiting at the origin gateway to cap per-second origin requests per content_id .

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