Compare Scenarios

Migration Step 1

Both scenarios define a migration step at this stage. Content Management Platform: triggered by 'Content read API p99 > 100ms during peak traffic; PostgreSQL'. Streaming Media Platform: triggered by 'Upload API p99 exceeding 30 seconds due to in-process transc'.

Migration Step 2

Both scenarios define a migration step at this stage. Content Management Platform: triggered by 'Full-text search p99 > 500ms; inability to implement faceted'. Streaming Media Platform: triggered by 'PostgreSQL viewing history table exceeding 500M rows; write '.

Migration Step 3

Both scenarios define a migration step at this stage. Content Management Platform: triggered by 'Month-end content performance reports generating sequential '. Streaming Media Platform: triggered by 'CDN provider incident causing total origin failover; CDN mis'.

PostgreSQL pg_stat_statements showing > 10 distinct query patterns with high call counts from the content list API path; database queries per second growing linearly with API request rate for content list endpoints (should be sub-linear with proper batch fetching); p99 for content list API > 200ms during moderate traffic

Tier 1: N+1 Query Amplification: ORM-level N+1 patterns in content relationship traversal: author fetch, category fetch, related content fetch as independent queries per article. Recommended evolution: Audit every content API response with query logging enabled and count queries per request for each content type; implement eager loading for all included relationships (JOIN for 1:1, IN-clause batch for 1:N); validate that content list endpoints produce a fixed number of queries regardless of list size (O(1) queries, not O(N)); add a query count assertion to integration tests for content list endpoints to prevent regression .

PostgreSQL read replica CPU spike correlated exactly with publish events; Redis cache hit rate dropping to near 0% immediately after publish for popular content; content API p99 spiking from < 20ms to > 500ms during the 1–3 second window after a high-traffic content item is published

Tier 2: Cache Invalidation Thundering Herd: Cache key deletion on publish triggering simultaneous cache miss stampede for all concurrent readers of popular content. Recommended evolution: Implement cache-aside with probabilistic early expiration (PER): before the cache TTL expires, a fraction of reads proactively refresh the cache value while other reads continue serving the cached value; this eliminates the hard expiry boundary that causes simultaneous misses; alternatively, on publish, write the new content value directly into the cache key before invalidating the old one (update-in-place rather than delete-and-miss) to eliminate the invalidation gap .

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 .