Rule-based disposition: any dimension at its most severe tier caps this at “concerns” or worse. Never an averaged score.
- Operational Readiness: ML Feature Serving Platform requires expert operational expertise at 'platform engineering team' level. Current readiness estimate is 21%, critical gaps must be resolved before adoption. Consider starting with a simpler scenario and evolving toward this one.
Architecture Review: ML Feature Serving Platform
A low-latency feature serving platform for ML model inference, providing both batch (offline) and real-time (online) feature access with strict training-serving consistency. Redis serves the hot feature cache with p99 latency targets below 5ms for online inference requests; PostgreSQL provides point-in-time feature lookups for offline training jobs with temporal consistency guarantees; Cassandra stores high-cardinality feature entities at write scale beyond PostgreSQL's single-primary ceiling; Kafka streams feature computation events from online feature pipelines to update the cache; Qdrant stores vector features for embedding-based model inputs and similarity lookups; ClickHouse serves feature analytics and drift monitoring across training dataset populations. Feature versioning is first-class: every feature value is tagged with a pipeline_version and computed_at timestamp to support model reproducibility and training-serving skew diagnosis.
Evidence Confidence
Moderate
strong
Executive Summary
ML Feature Serving Platform carries moderate operational readiness (82% evidence confidence). 0 architectural strengths identified, 6 operational risks to manage. Primary concern: Cache Stampede (Dog-Pile). Requires Advanced operational maturity.
Readiness Rationale
Overall moderate readiness across 8 dimensions. Limited: team maturity. Strong: migration, observability, failure recovery.
Key Concerns
- !Cache Stampede (Dog-Pile)
- !Embedding Drift
Key Strengths
- +Architecture is well-defined for the ai rag application problem profile
8
Assessments
3
Tradeoffs
6
Sections
12
Recommendations
Readiness Assessments
8Governance Posture
8Structural boundary and anti-pattern compliance: whether this architecture's topology violates documented governance policies. Distinct from operational readiness (below), which asks whether the team and infrastructure are prepared to run it.
8 governance policy matches and 1 anti-pattern match put ML Feature Serving Platform's governance posture at concerning risk. Resilience is limited; burden is extreme.
8
violations
1
anti-patterns
Governance Violations
Anti-Pattern Matches
Resilience
Blast radius: contained
46%
resilience score
Consistency Risks
- ·Qdrant vector index staleness after embedding model upgrade: when the embedding
Resilience Gaps
- △3 high-exposure risk nodes increase blast radius
Operational Burden
operational burden
100%
burden index
Complexity Drivers
- ⚙6 architecture patterns increase configuration surface
- ⚙Training-serving skew from cache-only feature serving: if online inference reads
- ⚙Feature pipeline version mismatch on model rollout: when a new model version is
Observability Burden
- ◎cassandra: requires dedicated monitoring instrumentation
- ◎clickhouse: requires dedicated monitoring instrumentation
- ◎kafka: requires dedicated monitoring instrumentation
- ◎postgresql: requires dedicated monitoring instrumentation
Recovery Complexity
- ⟳4 risk propagation path(s) complicate failure recovery
Maturity
Required
AdvancedEstimated
AdvancedGap
No GapThe architecture's required maturity (advanced) aligns with or is below the estimated team capability.
Operational Readiness
7Adoption readiness: whether the team, infrastructure, and observability are prepared to run this architecture safely. Distinct from governance posture (above), which asks whether the topology itself violates architectural boundaries.
ML Feature Serving Platform requires expert operational expertise at 'platform engineering team' level. Current readiness estimate is 21%, critical gaps must be resolved before adoption. Consider starting with a simpler scenario and evolving toward this one.
Readiness Score
21%
Blocking Prerequisites
4
Complexity
Expert
Confidence
Strong
Assessment derived from scenario knowledge, advisor output, topology analysis, and 7 prerequisite checks.
Prerequisite Checklist (4 blocking, 3 non-blocking)
team
Team at 'platform engineering team' maturity level
This scenario is rated 'platform engineering team' complexity.
Gap signal: Team frequently reaches for external help during incidents or struggles to debug multi-system issues independently.
process
Failure mode awareness and runbooks
The team must understand the 6 documented failure modes for this scenario: embedding_drift, vector_index_stale, cold_start_latency, cache_stampede. Each should have a documented detection procedure and runbook.
Gap signal: The team has no documented runbooks for the scenario's failure modes or cannot name them without reference material.
monitoring
Production-grade observability stack
The scenario requires real-time metrics, structured logging, and distributed tracing on all critical components. Alerting must be configured before going live.
Gap signal: No dashboards exist for the critical path metrics in the scenario.
infrastructure
Minimum team maturity: Platform Engineering Team
This scenario has expert operational complexity. It is recommended for Platform Engineering Team teams or higher.
Gap signal: The requirement 'Minimum team maturity: Platform Engineering Team' is not yet in place.
infrastructure
Runbooks and alerting for high-severity risks
3 high-severity risks identified. Each requires a documented runbook, alerting threshold, and on-call response procedure before running in production.
Gap signal: The requirement 'Runbooks and alerting for high-severity risks' is not yet in place.
infrastructure
Event stream operations expertise
This architecture includes event stream infrastructure (Kafka, Kinesis, or similar). Operations requires consumer group management, partition assignment, dead-letter handling, and lag monitoring.
Gap signal: The requirement 'Event stream operations expertise' is not yet in place.
infrastructure
Mitigation for 6 high-risk topology node(s)
Nodes with high or critical risk exposure: AI Embedding Lookup, Read-Heavy API Backend, Redis, Qdrant. Each requires documented mitigation before production deployment.
Gap signal: No mitigation strategy is documented for the high-risk nodes in the topology.
Infrastructure Requirements
Apache Cassandra
very_high burdenWide-column distributed database with linear write scalability, tunable consistency, and no single point of failure, designed for multi-datacenter dep
Managed: DataStax Astra DB, Amazon Keyspaces (Cassandra-compatible), Azure Managed Instance for Apache Cassandra
ClickHouse
medium burdenColumn-oriented OLAP database engineered for sub-second analytical queries on billions of rows, with vectorized execution, aggressive compression, and
Managed: ClickHouse Cloud, Altinity.Cloud
Apache Kafka
high burdenDistributed event streaming platform designed for high-throughput, fault-tolerant, ordered, and durable log-based messaging between producers and cons
Managed: Amazon MSK (Managed Streaming for Kafka), Confluent Cloud, Azure Event Hubs (Kafka-compatible), Redpanda Cloud
PostgreSQL
medium burdenACID-compliant relational database with strong consistency, JSONB support, full-text search, and mature replication.
Managed: Amazon RDS for PostgreSQL, Amazon Aurora PostgreSQL, Google Cloud SQL for PostgreSQL, Azure Database for PostgreSQL, Supabase, Neon
Qdrant
medium burdenPurpose-built vector database written in Rust, providing HNSW-based approximate nearest neighbor search with payload filtering, named vector support,
Redis
low burdenIn-memory key-value store with optional persistence, supporting strings, hashes, lists, sets, sorted sets, and pub/sub.
Managed: Amazon ElastiCache for Redis, Google Cloud Memorystore, Azure Cache for Redis, Redis Cloud, Upstash
Observability Requirements
Monitor generic risk probe signals
Seed 'Embedding Drift Risk Probe' identifies 2 metrics relevant to embedding_drift.
Seed 'Embedding Drift Risk Probe' identifies 2 metrics relevant to embedding_drift.
Track Embedding Drift exposure
Embedding Drift has high exposure and affects 3 components. Affects 3 nodes. (AI Embedding Lookup, Qdrant, Vector Similarity Search)
Embedding Drift has high exposure and affects 3 components. Affects 3 nodes. (AI Embedding Lookup, Qdrant, Vector Similarity Search)
Track Cache Stampede (Dog-Pile) exposure
Cache Stampede (Dog-Pile) has high exposure and affects 2 components. Affects 2 nodes. (Read-Heavy API Backend, Redis)
Cache Stampede (Dog-Pile) has high exposure and affects 2 components. Affects 2 nodes. (Read-Heavy API Backend, Redis)
Track Read Amplification (LSM Tree) exposure
Read Amplification (LSM Tree) has high exposure and affects 1 component. Affects 1 node. (Apache Cassandra)
Read Amplification (LSM Tree) has high exposure and affects 1 component. Affects 1 node. (Apache Cassandra)
Feature store p99 rising from < 5ms to > 50ms immediately following a model deployment or pod scaling event; Cassandra o
This signal indicates the architecture is approaching 'Tier 1: Cache Cold Start Latency Spike'. Likely bottleneck: Simultaneous cache cold start across all serving pods after deployment, converting sequential feature requests into a thundering herd against the backing feature store.
Tier 1: Cache Cold Start Latency Spike
Model performance metrics (precision, recall, AUC) degrading without a corresponding input distribution shift; ClickHous
This signal indicates the architecture is approaching 'Tier 2: Training-Serving Skew Detection'. Likely bottleneck: 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.
Tier 2: Training-Serving Skew Detection
Embedding model upgrade planned or in progress; Qdrant query recall metrics below threshold for new-model query vectors;
This signal indicates the architecture is approaching 'Tier 3: Qdrant Vector Index Rebuild Under Embedding Model Upgrade'. Likely bottleneck: Qdrant collection populated with old-model embeddings is incompatible with new-model query vectors: all indexed vectors must be recomputed and re-inserted.
Tier 3: Qdrant Vector Index Rebuild Under Embedding Model Upgrade
Readiness Action Plan
Satisfy: Team at 'platform engineering team' maturity level
Effort: 1–4 weeks depending on current state · Unblocks: Adoption of ML Feature Serving Platform
Satisfy: Failure mode awareness and runbooks
Effort: 1–4 weeks depending on current state · Unblocks: Adoption of ML Feature Serving Platform
Satisfy: Production-grade observability stack
Effort: 1–4 weeks depending on current state · Unblocks: Adoption of ML Feature Serving Platform
Satisfy: Mitigation for 6 high-risk topology node(s)
Effort: 1–4 weeks depending on current state · Unblocks: Adoption of ML Feature Serving Platform
Instrument all critical path components with metrics and alerting
Effort: 1–2 weeks · Unblocks: Safe production adoption and incident response
Validate adoption in a staging environment before production
Effort: 2–4 weeks for thorough staging validation · Unblocks: Production confidence and rollback preparedness
Mitigate risk: Embedding Drift
Effort: 1–3 weeks · Unblocks: Reduces 'Embedding Drift' from blocking adoption
Mitigate risk: Cache Stampede (Dog-Pile)
Effort: 1–3 weeks · Unblocks: Reduces 'Cache Stampede (Dog-Pile)' from blocking adoption
Go Signals
- ✓Team has hands-on experience with all 6 referenced technologies.
- ✓All scenario failure modes have documented runbooks and alerting coverage.
- ✓A staging environment that mirrors production load has been tested successfully.
No-Go Signals
- ✗Team cannot explain or debug any of ML Feature Serving Platform's documented failure modes.
- ✗No observability baseline exists for the critical components.
- ✗Top risk is unmitigated: 'Embedding Drift', do not proceed without addressing this.
Critical Gaps
- This scenario has expert operational complexity, teams without deep production experience will struggle to operate it safely.
Team Requirements
Apache Cassandra operations
Required level: proficient
Team can explain Apache Cassandra's failure modes, tune configuration parameters under load, and recover from common operational issues.
Apache Kafka operations
Required level: proficient
Team can explain Apache Kafka's failure modes, tune configuration parameters under load, and recover from common operational issues.
PostgreSQL operations
Required level: proficient
Team can explain PostgreSQL's failure modes, tune configuration parameters under load, and recover from common operational issues.
Qdrant operations
Required level: proficient
Team can explain Qdrant's failure modes, tune configuration parameters under load, and recover from common operational issues.
Redis operations
Required level: proficient
Team can explain Redis's failure modes, tune configuration parameters under load, and recover from common operational issues.
Readiness assessment is derived from structured scenario and topology knowledge. It provides an evidence-grounded baseline, not a substitute for an actual team capability review or infrastructure audit. Validate each item against your specific environment.
Architectural Tradeoffs
3Recommendations
12Monitor: Embedding Drift
risk_monitoringVector embeddings become semantically stale when source document content changes but the stored embedding is not regenerated: causing semantic search and RAG retrieval to return outdated, incorrect, or misleading results without any error signal, silently degrading the quality of AI-backed features.
Affects 3 nodes. (AI Embedding Lookup, Qdrant, Vector Similarity Search)
Monitor: Cache Stampede (Dog-Pile)
risk_monitoringWhen a widely-shared cached value expires or is invalidated, all concurrent requests that miss simultaneously trigger identical expensive database queries, overwhelming the origin store before any single result can be computed and cached: a positive feedback loop that can collapse the database within seconds.
Affects 2 nodes. (Read-Heavy API Backend, Redis)
Implement: Monitor generic risk probe signals
observabilitySeed 'Embedding Drift Risk Probe' identifies 2 metrics relevant to embedding_drift.
Metrics to instrument: error_rate, p95_latency_ms
No stampede-protection mechanism recorded
caching'ML Feature Serving Platform' is flagged vulnerable to cache stampede, but no carried pattern documents a mutex lock, probabilistic early expiry, or TTL jitter mechanism. This does not mean the mechanism is absent in a real deployment, only that no such mitigation is recorded in this scenario's structured knowledge yet.
Without one of these mechanisms, a hot-key expiry can produce a database load spike; see cache_stampede for the full mitigation list.
Features computed inline in the inference service with no shared feature store → Centralized feature store with Redis cache and Cassandra backing store
migration_planningTrigger: Feature computation logic duplicated across 3+ model serving services with no coordination; training-serving skew discovered after model deployment causing unexplained model performance regression; feature computation latency dominating inference latency for complex features; inability to enforce feature versioning across model versions. Migrate from 'Features computed inline in the inference service with no shared feature store' to 'Centralized feature store with Redis cache and Cassandra backing store'. Identify the 10 most reused features across models and migrate those first. Validate that feature values from the central store match inline-computed values before migrating any model serving path to use the store.
Initial feature store population requires backfilling historical feature values for all entity IDs: backfill jobs must be idempotent and resumable to handle interruptions; Migrating from inline computation to feature store lookups requires model serving code changes across all inference services simultaneously or a dual-lookup period
Latest-value-only feature store with no temporal history → Point-in-time feature store with training-time lookup support
migration_planningTrigger: Regulatory or reproducibility requirement to re-run model predictions at a historical point in time; training data contamination investigation requiring knowledge of what features were available at training label creation time; model backtesting requiring consistent feature snapshots across historical time ranges. Migrate from 'Latest-value-only feature store with no temporal history' to 'Point-in-time feature store with training-time lookup support'. Add computed_at and valid_until columns to the feature store schema first. Start writing temporal feature records in parallel with the existing latest-value records. Migrate training jobs one at a time to use point-in-time lookups, validating that model performance does not change from the temporal semantics change.
Point-in-time storage requires retaining every feature update with its timestamp rather than overwriting the latest value: storage volume increases by the number of feature updates per entity per time window; Existing training pipelines that read "current" feature values must be updated to read "feature value as-of label timestamp": this changes training job semantics and requires validation
Prepare runbook for: Burst Traffic Cold Cache Stampede
simulation_preparednessSimulation demonstrates critical degradation of redis, postgresql
Without a runbook, recovery from this failure mode will be ad-hoc
Prepare runbook for: Connection Pool Exhaustion with Horizontal User Scale
simulation_preparednessSimulation demonstrates critical degradation of postgresql
Without a runbook, recovery from this failure mode will be ad-hoc
Plan evolution: OLTP Analytics Queries → OLTP + OLAP Separation
evolution_planningEvolution from Unified OLTP + Analytics on PostgreSQL → Separated OLTP (PostgreSQL) + OLAP (ClickHouse/Snowflake)
Migration complexity: medium. Rollback: always.
Plan evolution: Single Cache Layer → Distributed Cache
evolution_planningEvolution from Single Redis Node / Sentinel Cluster → Distributed Redis Cluster (Consistent Hash Ring)
Migration complexity: medium. Rollback: complex.
Cache-outage database fallback load
caching'ML Feature Serving Platform' includes a cache in its topology. If the cache becomes unavailable, the primary database receives the cache's full request load until the cache recovers.
Capacity-plan the primary database for this fallback load, not only for the steady-state cached load.
Cache invalidation ownership
cachingCache invalidation for ML Feature Serving Platform is event-driven: kafka refreshes or invalidates redis. This couples cache freshness to consumer lag on that event stream, not to the primary write path directly.
If the event-stream consumer falls behind, the cache serves stale data until it catches up -- monitor consumer lag as a cache-freshness signal, not only a backlog signal.
Scaling Pressure Signals
8Feature 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
Threshold
Tier 1: Cache Cold Start Latency Spike
Likely Bottleneck
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
Threshold
Tier 2: Training-Serving Skew Detection
Likely Bottleneck
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.
Embedding model upgrade planned or in progress; Qdrant query recall metrics below threshold for new-model query vectors; similarity search results visibly degraded for new-model queries against old-model index; full re-indexing job running for hours against Qdrant collection
Threshold
Tier 3: Qdrant Vector Index Rebuild Under Embedding Model Upgrade
Likely Bottleneck
Qdrant collection populated with old-model embeddings is incompatible with new-model query vectors: all indexed vectors must be recomputed and re-inserted
Recommended Evolution
Maintain two Qdrant collections per embedding model version (v1 and v2) simultaneously during embedding model transitions. Serve queries from the new-model collection as soon as re-indexing is complete, then deprecate the old collection. This requires that embedding model version is a first-class routing parameter in the feature serving path, not an implicit global. Re-indexing must be triggered and validated before the model serving path is pointed at the new collection.
Cassandra feature store write p99 > 20ms under online pipeline update rate; Kafka online feature computation consumer consistently lagging behind the event stream; feature freshness SLA violations (features served are older than the required freshness window); Cassandra compaction backlog growing under sustained high-frequency feature updates
Threshold
Tier 4: Feature Store Write Throughput Ceiling for Online Pipeline
Likely Bottleneck
Online feature pipeline writing updates for millions of entities at high frequency saturating Cassandra write throughput through compaction pressure and partition hot spots
Recommended Evolution
Tune Cassandra compaction strategy to TWCS (TimeWindowCompactionStrategy) for time-ordered feature updates: this reduces compaction amplification for append-heavy feature pipelines. Introduce write batching at the feature pipeline layer: group feature updates by partition key and batch-write using logged batches to reduce coordinator round-trips. For the highest-throughput feature types, evaluate ScyllaDB as a drop-in Cassandra replacement with significantly higher write throughput at equivalent hardware.
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
Threshold
Escalation trigger: Simultaneous cache cold start across all serving pods after deployment, converting sequential feature requests into a thundering herd against the backing feature store
Likely Bottleneck
Tier 1: Cache Cold Start Latency Spike
Recommended Evolution
Monitor: error_rate, p95_latency_ms
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
Threshold
Escalation trigger: 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
Likely Bottleneck
Tier 2: Training-Serving Skew Detection
Recommended Evolution
Monitor: error_rate, p95_latency_ms
Embedding model upgrade planned or in progress; Qdrant query recall metrics below threshold for new-model query vectors; similarity search results visibly degraded for new-model queries against old-model index; full re-indexing job running for hours against Qdrant collection
Threshold
Escalation trigger: Qdrant collection populated with old-model embeddings is incompatible with new-model query vectors: all indexed vectors must be recomputed and re-inserted
Likely Bottleneck
Tier 3: Qdrant Vector Index Rebuild Under Embedding Model Upgrade
Recommended Evolution
Monitor: error_rate, p95_latency_ms
Cassandra feature store write p99 > 20ms under online pipeline update rate; Kafka online feature computation consumer consistently lagging behind the event stream; feature freshness SLA violations (features served are older than the required freshness window); Cassandra compaction backlog growing under sustained high-frequency feature updates
Threshold
Escalation trigger: Online feature pipeline writing updates for millions of entities at high frequency saturating Cassandra write throughput through compaction pressure and partition hot spots
Likely Bottleneck
Tier 4: Feature Store Write Throughput Ceiling for Online Pipeline
Recommended Evolution
Monitor: error_rate, p95_latency_ms
Migration Readiness
12Migration Stages
3Features computed inline in the inference service with no shared feature store → Centralized feature store with Redis cache and Cassandra backing store
infoMigration trigger: Feature computation logic duplicated across 3+ model serving services with no coordination; training-serving skew discovered after model deployment causing unexplained model performance regression; feature computation latency dominating inference latency for complex features; inability to enforce feature versioning across model versions
Latest-value-only feature store with no temporal history → Point-in-time feature store with training-time lookup support
infoMigration trigger: Regulatory or reproducibility requirement to re-run model predictions at a historical point in time; training data contamination investigation requiring knowledge of what features were available at training label creation time; model backtesting requiring consistent feature snapshots across historical time ranges
Text similarity search via PostgreSQL full-text tsvector → Qdrant vector similarity search with pre-computed embeddings
infoMigration trigger: Semantic similarity search recall insufficient from BM25 full-text scoring; user query matching requiring understanding of synonyms, paraphrases, or cross-language similarity; feature retrieval for embedding-based ranking models requiring approximate nearest-neighbor search with p99 < 10ms
Risks
9Initial feature store population requires backfilling histor
warningInitial feature store population requires backfilling historical feature values for all entity IDs: backfill jobs must be idempotent and resumable to handle interruptions
Migrating from inline computation to feature store lookups r
warningMigrating from inline computation to feature store lookups requires model serving code changes across all inference services simultaneously or a dual-lookup period
Point-in-time storage requires retaining every feature updat
warningPoint-in-time storage requires retaining every feature update with its timestamp rather than overwriting the latest value: storage volume increases by the number of feature updates per entity per time window
Existing training pipelines that read "current" feature valu
warningExisting training pipelines that read "current" feature values must be updated to read "feature value as-of label timestamp": this changes training job semantics and requires validation
Qdrant approximate nearest-neighbor recall depends on index
warningQdrant approximate nearest-neighbor recall depends on index parameters (ef_construction, m) tuned during index build: incorrect parameters produce fast but low-recall results with no error signal
Embedding model must be fixed at index build time; changing
warningEmbedding model must be fixed at index build time; changing the model requires full re-indexing; this must be planned as a first-class operational procedure
Projection lag creates a read-after-write window where users
criticalProjection lag creates a read-after-write window where users see stale data after their own writes. Mitigation: Route immediate post-write reads to the write store (session-scoped write token); accept eventual consistency only for non-user-initiated reads
↗ direct-db-to-cqrsProjection rebuild after schema change can take hours or day
criticalProjection rebuild after schema change can take hours or days on large datasets. Mitigation: Design blue/green projection deployment: build new projection in parallel before switching traffic; test rebuild time in staging
↗ direct-db-to-cqrsCross-service workflows that previously used database transa
criticalCross-service workflows that previously used database transactions now require Saga orchestration. Mitigation: Design idempotent event handlers; implement compensating transactions for every multi-step workflow; test failure injection in staging
↗ modular-monolith-to-event-driven