Cassandra medium
You partition a multi-tenant 'Chat' table by `Tenant_ID`. One tenant is 1000x larger than others. What is the specific architectural failure result?
- A Cassandra automatically shares the tenant's data across all cluster nodes to balance the load.
- B Data Skew: One node in the cluster becomes the 'Hot Node', owning a massive partition that consumes 100% of its disk and CPU, while the rest of the cluster stays idle.
- C The cluster will enter a 'Self-Correction' mode and rename the Tenant ID to a hash value.
- D This is a requested feature in Cassandra called 'Master Tenant Routing'.
Answer: B. Data Skew: One node in the cluster becomes the 'Hot Node', owning a massive partition that consumes 100% of its disk and CPU, while the rest of the cluster stays idle.
This is a classic 'Design Fail'. Hashing ensures even distribution of *keys*, but not even distribution of *data volume*. You must ensure your partition keys are granular enough (e.g., `(Tenant_ID, Month_Bucket)`) to prevent a single physical server from being overloaded.
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?