What is Apache Cassandra?

Answer:

Apache Cassandra is an open-source, distributed NoSQL database designed to handle large amounts of data across many commodity servers with no single point of failure.

Created by: Facebook engineers Avinash Lakshman and Prashant Malik in 2008

Why it was created:

• Facebook needed to handle massive inbox search features across billions of users
• Traditional databases couldn't scale horizontally to meet their needs
• Required high availability with no downtime during server failures
• Needed a database that could run across multiple datacenters globally

Fun Fact: Cassandra combines the best of Amazon's Dynamo (distributed design) and Google's BigTable (data model)!

Answer:

Cassandra is a NoSQL Wide-Column Store Database.

Key Characteristics:

• NoSQL: Doesn't use SQL's relational model with tables and foreign keys
• Wide-Column Store: Data stored in rows with flexible columns (unlike fixed columns in RDBMS)
• Distributed: Data spread across multiple nodes in a cluster
• Schema-Optional: Flexible schema that can evolve over time
• Decentralized: No master-slave architecture; all nodes are equal

Comparison:

• Different from Document Stores (MongoDB)
• Different from Key-Value Stores (Redis)
• Different from Graph Databases (Neo4j)

Answer:

Top 8 Advantages:

• 1. High Availability (99.99% uptime): No single point of failure means your system stays running even during hardware failures
• 2. Linear Scalability: Double your servers = double your throughput. Scale from 3 to 300+ nodes seamlessly
• 3. Exceptional Write Performance: Optimized for write-heavy workloads. Can handle millions of writes per second
• 4. Multi-Datacenter Support: Built-in replication across geographic locations for disaster recovery
• 5. Fault Tolerance: Data automatically replicated to multiple nodes. Node failures handled automatically
• 6. Tunable Consistency: Choose consistency level per query based on your needs
• 7. Flexible Schema: Add/remove columns without downtime or migration scripts
• 8. Cost-Effective: Runs on commodity hardware, no need for expensive enterprise servers

Real-World Impact: Companies save millions in infrastructure costs while serving billions of users!

Answer:

"No Single Point of Failure" means there's no single server that, if it fails, brings down the entire system.

How Cassandra Achieves This:

• Peer-to-Peer Architecture: All nodes are equal - no master node controlling everything
• Data Replication: Each piece of data is copied to multiple nodes (typically 3 replicas)
• Automatic Failover: If one node fails, other replicas serve the data immediately
• Continuous Availability: System continues operating while failed nodes are repaired or replaced

Real-World Example:

Netflix has hundreds of Cassandra nodes. If 5 nodes fail simultaneously during peak hours, users don't even notice - other nodes take over instantly!

Comparison with Traditional Databases:

• MySQL Master-Slave: If master fails, manual intervention needed to promote slave
• Cassandra: Automatic, instant failover with zero human intervention

Answer:

Cassandra uses a Ring Architecture where nodes are organized in a circular pattern with no hierarchical relationships.

Key Components:

• Token Ring: Virtual circular space divided among nodes (0 to 2^63-1)
• Token Assignment: Each node gets a token range representing data it owns
• Equal Nodes: Every node can handle read/write requests - no master/slave
• Data Distribution: Data partitioned based on partition key's hash value

Example with 6 Nodes:

• Node 1: Token 0 to 42
• Node 2: Token 43 to 84
• Node 3: Token 85 to 126
• Node 4: Token 127 to 169
• Node 5: Token 170 to 211
• Node 6: Token 212 to 255 (wraps back to 0)

Benefits:

• Easy to add/remove nodes - just redistribute tokens
• Load automatically balanced across all nodes
• No bottleneck from a single master node

Answer:

The CAP Theorem states that a distributed database can only guarantee 2 out of 3 properties:

• C - Consistency: All nodes see the same data at the same time
• A - Availability: Every request receives a response (success or failure)
• P - Partition Tolerance: System continues operating despite network failures

Cassandra's Position: AP System (with tunable C)

• Availability: System always responds to requests (prioritizes availability)
• Partition Tolerance: Continues operating during network splits
• Consistency: Eventually consistent by default, but you can tune it!

Tunable Consistency Levels:

• ONE: Fastest, least consistent (AP-focused)
• QUORUM: Balanced approach (majority must agree)
• ALL: Strongest consistency, sacrifices availability (CP-like)

Why This Matters: Unlike traditional databases that force you into one model, Cassandra lets YOU choose the tradeoff per query!

Answer:

Cassandra is powerful but not suitable for every use case. Avoid Cassandra if:

• 1. You Need Complex Joins: Cassandra doesn't support joins between tables. If your queries require multi-table joins, use PostgreSQL
• 2. Small Dataset (< 100GB): Overhead of distributed architecture not worth it. Use MySQL or PostgreSQL
• 3. ACID Transactions Across Rows: Cassandra only guarantees row-level atomicity, not multi-row transactions
• 4. Aggregations and Analytics: Complex GROUP BY queries are slow. Use columnar databases like ClickHouse
• 5. Rapidly Changing Schema: While flexible, frequent schema changes in production can be tricky
• 6. Ad-hoc Queries: Cassandra requires query-driven data modeling. Can't easily query data in ways you didn't plan for
• 7. Strong Consistency Always Required: If eventual consistency is unacceptable, consider traditional RDBMS

Better Alternatives:

• Complex queries + ACID: PostgreSQL, MySQL
• Analytics: ClickHouse, Snowflake
• Full-text search: Elasticsearch
• Graph relationships: Neo4j

Answer:

Key Differences:

• Data Model:
  • MongoDB: Document-oriented (JSON-like documents)
  • Cassandra: Wide-column store (rows with flexible columns)
• Architecture:
  • MongoDB: Master-Slave (has primary and secondary nodes)
  • Cassandra: Peer-to-Peer (all nodes equal, no master)
• Consistency:
  • MongoDB: Strong consistency by default
  • Cassandra: Eventual consistency by default (tunable)
• Query Language:
  • MongoDB: Rich query language, ad-hoc queries supported
  • Cassandra: CQL (SQL-like), requires query planning
• Scalability:
  • MongoDB: Horizontal sharding (manual configuration)
  • Cassandra: Linear scalability (automatic)
• Write Performance:
  • MongoDB: Good for mixed workloads
  • Cassandra: Exceptional for write-heavy workloads

Choose MongoDB if: You need flexible schema, complex queries, and strong consistency

Choose Cassandra if: You need massive scale, high availability, and write performance

Answer:

Major Companies Using Cassandra:

• Netflix: 2,500+ nodes, serves 100M+ subscribers globally
• Apple: 100,000+ nodes for iCloud services
• Instagram: Stores 100B+ photos for 400M+ users
• Uber: Real-time trip data, driver locations for millions of rides daily
• Twitter: User timeline and analytics
• Discord: Message storage and delivery for millions of gamers
• Reddit: Handles billions of posts and comments
• eBay: Product catalog and search
• GitHub: Audit logging and activity feeds
• Hulu: Video streaming analytics

Common Use Cases:

• Time-series data (IoT sensors, logs)
• Messaging platforms
• Social media feeds
• Product catalogs
• Real-time analytics

Answer:

Cassandra's write path is optimized for speed and consists of three main steps:

Write Process:

• 1. Commit Log (Disk Write):
  • First, data written to append-only commit log on disk
  • Ensures durability - data survives node crashes
  • Sequential disk writes are extremely fast!
• 2. Memtable (Memory Write):
  • Simultaneously written to in-memory structure called Memtable
  • Sorted data structure for fast access
  • Batches multiple writes before flushing to disk
• 3. SSTable (Eventual Disk Flush):
  • When Memtable fills up, flushed to disk as SSTable (Sorted String Table)
  • Immutable once written (never modified, only replaced)
  • Multiple SSTables compacted periodically

Why This is Fast:

• Memory writes are instant (Memtable)
• Disk writes are sequential (Commit Log)
• No read-before-write needed
• No index updates during writes

Result: Cassandra can handle millions of writes per second!

Answer:

Replication Factor (RF) determines how many copies of each piece of data are stored across the cluster.

Common Replication Factors:

• RF = 1: Single copy (NOT RECOMMENDED - no fault tolerance!)
• RF = 3: Three copies (MOST COMMON - good balance)
• RF = 5: Five copies (high availability, more storage cost)

Example with RF=3 and 6 Nodes:

• Data X stored on Node 1
• Automatically replicated to Node 2 and Node 3
• If Node 1 fails, Nodes 2 and 3 still have the data
• Can lose 2 nodes and data still available!

Benefits:

• Fault Tolerance: System survives node failures
• High Availability: Data always accessible
• Read Performance: Queries can read from any replica

Trade-off: Higher RF = More storage required, but better availability

Production Recommendation: Always use RF=3 minimum!

Answer:

Eventual Consistency means that after a write, all replicas will eventually have the same data, but not necessarily immediately.

How It Works:

• Write happens: Data written to one node successfully
• Async Replication: Data asynchronously copied to other replicas
• During replication: Different replicas might have slightly different data
• After replication: All replicas eventually consistent

Example Scenario:

• User A updates profile picture (writes to Node 1)
• User B immediately views profile (reads from Node 2)
• User B might see old picture for a few milliseconds
• After replication completes, User B sees new picture

Benefits:

• Higher availability (system always responsive)
• Better write performance (no need to wait for all replicas)
• Lower latency

When It's OK:

• Social media likes/views counts
• Product recommendations
• User activity feeds

When It's NOT OK:

• Financial transactions
• Inventory counts
• User authentication

Solution: Use higher consistency levels (QUORUM or ALL) for critical data!

Answer:

CQL (Cassandra Query Language) is Cassandra's query language, designed to look similar to SQL but optimized for distributed databases.

Key Features:

• SQL-like Syntax: Easy for developers familiar with SQL
• Different Semantics: Looks like SQL but behaves differently underneath
• No Joins: Cannot join tables like traditional SQL
• Denormalization Required: Data modeling approach is completely different

Example CQL Commands:

• Create Keyspace: CREATE KEYSPACE users WITH REPLICATION = {'class': 'SimpleStrategy', 'replication_factor': 3};
• Create Table: CREATE TABLE users (user_id UUID PRIMARY KEY, name TEXT, email TEXT);
• Insert Data: INSERT INTO users (user_id, name, email) VALUES (uuid(), 'John', '[email protected]');
• Query Data: SELECT * FROM users WHERE user_id = ?;

Important Differences from SQL:

• Must include partition key in WHERE clause
• Cannot query on arbitrary columns without indexes
• No GROUP BY, no complex aggregations
• ALLOW FILTERING discouraged in production

Learning Tip: Don't think of CQL as SQL. It's a different paradigm designed for distributed systems!

Answer:

A Keyspace is the top-level database container in Cassandra, similar to a "database" or "schema" in traditional RDBMS.

What Keyspace Defines:

• Replication Strategy: How data is replicated across nodes
• Replication Factor: Number of replicas for data
• Data Center Strategy: Multi-datacenter configuration
• Container for Tables: All tables exist within a keyspace

Example Creation:

CREATE KEYSPACE my_app 
WITH REPLICATION = {
  'class': 'NetworkTopologyStrategy',
  'datacenter1': 3,
  'datacenter2': 2
};

Common Replication Strategies:

• SimpleStrategy: For single datacenter (dev/test environments)
• NetworkTopologyStrategy: For production multi-datacenter setups

Best Practices:

• One keyspace per application
• Use NetworkTopologyStrategy in production
• RF = 3 minimum for production
• Name keyspaces lowercase with underscores

Comparison: Keyspace in Cassandra = Database in MySQL

Answer:

Essential Skills for Cassandra Developers:

• 1. Distributed Systems Concepts:
  • CAP theorem understanding
  • Eventual consistency vs strong consistency
  • Partitioning and replication strategies
• 2. CQL Proficiency:
  • Create keyspaces and tables
  • Write efficient queries
  • Understand partition keys and clustering columns
• 3. Data Modeling:
  • Query-driven design approach
  • Denormalization techniques
  • Partition key selection
  • Avoiding anti-patterns
• 4. Operations & Monitoring:
  • nodetool commands
  • Cluster maintenance
  • Performance tuning
  • Monitoring tools (DataStax OpsCenter, Prometheus)
• 5. Programming:
  • Java, Python, or Node.js drivers
  • Async programming concepts
  • Connection pooling

Learning Path:

• Week 1-2: Architecture and concepts
• Week 3-4: CQL and data modeling
• Week 5-6: Hands-on projects
• Week 7-8: Operations and tuning

Career Opportunities: Cassandra skills are in high demand! Average salary for Cassandra developers: $120K-180K/year