Cassandra medium
Cassandra supports Materialized Views (MVs) to handle automatic denormalization. What is the primary 'Operational Safeguard' concern regarding MV consistency?
- A Materialized Views are always synchronous and will block the client for 2 minutes for every write.
- B Asynchronous Divergence: If the 'Shadow Write' to the View fails (due to a node crash), the View and the Base table can become permanently out of sync without a manual repair.
- C Materialized Views only work if the cluster has exactly 12 nodes.
- D Materialized Views cannot be used if the table contains string data.
Answer: B. Asynchronous Divergence: If the 'Shadow Write' to the View fails (due to a node crash), the View and the Base table can become permanently out of sync without a manual repair.
Materialized Views are technically a 'Secondary Write'. Since they happen across different partition keys, they aren't 'Atomic' with the base write. Many high-scale architectures prefer 'Application-Side Denormalization' to have more control over failure modes.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- In a Cassandra Keyspace, what does a 'Replication Factor of 3' specifically guarantee for your data redundancy?
- Unlike a Leader-Follower architecture (like MySQL or Redis), how does Cassandra maintain high availability within its node cluster?
- Cassandra Query Language (CQL) looks similar to SQL. What is a fundamental SQL feature that CQL does NOT support to ensure distributed performance?
- What is the critical architectural function of the 'Partition Key' in a Cassandra table?
- Apache Cassandra is fundamentally designed as which architectural category of NoSQL database?
- An extreme financial trading application requires 'Batch' sync for the Commit Log. What is the fundamental throughput limitation introduced by this setting?