Cassandra hard
In a high-contention environment where multiple microservices try to update the same row using LWT (`IF` clause), why does throughput often drop to near-zero?
- A Because Paxos locks the entire keyspace for the duration of the request.
- B Paxos Livelock: Multiple coordinators keep proposing new ballot numbers for the same row. Each rejects the other's proposal as 'Stale', forcing constant retries and consuming CPU with no successful writes.
- C LWT is disabled automatically by the kernel when more than 5 clients connect.
- D Paxos writes are written to a specialized 'Slow Disk' partition by default.
Answer: B. Paxos Livelock: Multiple coordinators keep proposing new ballot numbers for the same row. Each rejects the other's proposal as 'Stale', forcing constant retries and consuming CPU with no successful writes.
This is often called a 'CAS Loop' collision. In a distributed Paxos implementation, if two nodes try to be the 'Proposer' for the same key at the same time, they interfere with each other's state machine. To fix this, you should use a single dedicated service to serialize updates or use standard (non-LWT) writes with timestamps.
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?