Cassandra hard
Cassandra's `Speculative Retry` is an implementation of 'Hedging Requests'. What specific problem in high-scale distributed systems does it solve?
- A It solves the double-spending problem in blockchain.
- B It fixes data corruption caused by radiation.
- C The Tail Latency (Long Tail) problem: One single node experiencing a JVM GC pause or a slow disk sector won't drag down the P99.9 latency of the entire application.
- D It allows the database to stay online even if 100% of nodes are down.
Answer: C. The Tail Latency (Long Tail) problem: One single node experiencing a JVM GC pause or a slow disk sector won't drag down the P99.9 latency of the entire application.
If a Read takes longer than average (e.g., 50ms), the Coordinator assumes that node is 'hiccoughing' and asks another replica for the same data simultaneously. Whichever responds first wins. This 'hedging' ensures that the user doesn't wait for a slow server (The 'Outlier').
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?