Bird
Raised Fist0

Wide-Column Stores - Cassandra Partitioning and Data Modeling

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
Client API

Sends read request

Client issues a read request for user data

Protocol:HTTP
BeforeUser data only on client device
AfterRequest sent to Load Balancer
Load Balancer / Coordinator Nodes

Receives and routes request

Load balancer forwards CQL query to Cassandra cluster

Protocol:CQL
BeforeRequest received from client
AfterQuery dispatched to Cassandra nodes based on partition key
Partition Key

Determines data node

Partition key hashes to select Cassandra node holding data

Protocol:Internal hashing
BeforeQuery unassigned to node
AfterQuery routed to correct node partition
Clustering Columns

Sorts data within partition

Clustering columns used to locate exact rows in partition

Protocol:Internal query processing
BeforePartition data located
AfterRows sorted and filtered by clustering columns
Storage on SSDs

Reads data from disk

Data retrieved from SSD storage for requested rows

Protocol:Disk I/O
BeforeRows identified in memory
AfterData returned to coordinator node
Load Balancer / Coordinator Nodes

Aggregates and returns data

Coordinator compiles data and sends response to client

Protocol:CQL Response
BeforeData received from storage nodes
AfterResponse sent back to client API
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│  Client API   │
└───────┬───────┘
        │ HTTP Request
        ▼
┌───────────────────────────────┐
│ Load Balancer / Coord. Nodes  │
└───────────────┬───────────────┘
                │ CQL Query
                ▼
┌───────────────────────────────┐
│ Cassandra Cluster              │
│ ┌───────────────┐             │
│ │Partition Key  │             │
│ └──────┬────────┘             │
│        │                       │
│ ┌──────▼────────┐             │
│ │Clustering     │             │
│ │Columns        │             │
│ └──────┬────────┘             │
│        │                       │
│ ┌──────▼────────┐             │
│ │Storage on SSDs│             │
│ └───────────────┘             │
└───────────────────────────────┘
Design Rationale

This architecture illustrates how a client read request flows through a Cassandra wide-column store. The Client API sends an HTTP request to the Load Balancer / Coordinator Nodes, which translate it into a CQL query. The partition key hashes the query to the correct Cassandra node, ensuring data locality and scalability. Clustering columns then sort and filter data within the partition for efficient retrieval. Finally, data is read from SSD storage and returned through the coordinator to the client. This design highlights Cassandra's partitioning and data modeling principles that optimize for distributed, scalable, and fast data access.

Primary Focus

✓

Practice

(1/5)
1. A distributed database system needs to evenly distribute data across 100 shards and handle dynamic addition/removal of shards with minimal data movement. Which component is most appropriate to manage shard assignment?
easy
A. Use a modulo-based hash function on the primary key to assign shards directly
B. Implement consistent hashing with virtual nodes to map keys to shards
C. Assign shards based on a centralized lookup table updated on every shard change
D. Use range-based partitioning with fixed key ranges per shard

Solution

  1. Step 1: Understand shard assignment requirements

    Modulo hashing (Use a modulo-based hash function on the primary key to assign shards directly) causes massive remapping when shards change; centralized lookup (Assign shards based on a centralized lookup table updated on every shard change) creates a bottleneck and single point of failure; range partitioning (Use range-based partitioning with fixed key ranges per shard) can cause hotspots and uneven load.

  2. Step 2: Evaluate consistent hashing benefits

    Consistent hashing with virtual nodes (Implement consistent hashing with virtual nodes to map keys to shards) evenly distributes keys and minimizes remapping when shards are added or removed, making it ideal for dynamic shard management.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Consistent hashing minimizes shard remapping on topology changes [check]
Hint: Consistent hashing minimizes data movement on shard changes [OK]
Common Mistakes:
2. In a request flow where a client sends a request through a forward proxy to an external server, at step 3 the forward proxy modifies the request headers. What exactly happens at this step?
easy
A. The forward proxy removes client-identifying headers and adds its own IP as the source
B. The forward proxy caches the response before forwarding the request
C. The forward proxy encrypts the entire request payload before forwarding
D. The forward proxy replaces the destination IP with its own IP before forwarding

Solution

  1. Step 1: Understand forward proxy header modification

    At step 3, the forward proxy removes headers that reveal client identity and inserts its own IP as the source to hide the client.

  2. Step 2: Eliminate other options

    It does not replace destination IP (that would break routing), nor encrypt payload (that's TLS), nor cache response before request forwarding.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Forward proxy masks client IP by header modification [check]
Hint: Forward proxy swaps client IP with its own in headers [check]
Common Mistakes:
3. For delivering notifications to mobile devices at 10M+ scale, which architecture better handles intermittent connectivity and battery constraints?
medium
A. Use push notification services (APNs, FCM) with message TTL and retries managed by the platform
B. Use persistent gRPC streaming connections from server to device for real-time delivery
C. Use long polling HTTP connections from device to server to fetch notifications
D. Use SMS as the primary delivery channel for all notifications

Solution

  1. Step 1: Evaluate persistent connection approaches

    gRPC streaming (A) is unreliable on mobile due to network changes and battery constraints; long polling (C) wastes battery and bandwidth.

  2. Step 2: Consider platform push services and SMS

    Push services (B) handle retries and offline buffering efficiently; SMS (D) is costly and not suitable for all notifications.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Platform push services manage retries and offline buffering [check]
Hint: Use platform push services, not persistent streams on mobile [check]
Common Mistakes:
4. For ensuring exactly-once payment processing in a distributed payment system, which architecture is best suited given high throughput and fault tolerance requirements?
medium
A. Use an event-driven architecture with Kafka for event sourcing and idempotent consumers
B. Use a synchronous two-phase commit protocol across all services to guarantee atomicity
C. Use a centralized relational database with serializable transactions for all payment states
D. Use client-side retries with unique request IDs and eventual consistency in backend

Solution

  1. Step 1: Analyze architecture trade-offs

    Synchronous two-phase commit (Use a synchronous two-phase commit protocol across all services to guarantee atomicity) blocks and reduces throughput; centralized DB (Use a centralized relational database with serializable transactions for all payment states) limits scalability; client-side retries (Use client-side retries with unique request IDs and eventual consistency in backend) risk inconsistent states.

  2. Step 2: Evaluate event-driven approach

    Kafka event sourcing with idempotent consumers supports high throughput, fault tolerance, and exactly-once processing semantics.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Kafka event sourcing -> scalable, fault-tolerant, idempotent processing [check]
Hint: Event sourcing with idempotent consumers scales best [check]
Common Mistakes:
5. If the PageRank computation component fails during an update cycle, what is the immediate impact on search result ranking and user experience?
medium
A. Search results become completely unavailable until PageRank recovers
B. Search results degrade to random ordering because PageRank scores are missing
C. The indexing pipeline halts, blocking new documents from being indexed
D. Search results continue serving the last successful PageRank snapshot without updates

Solution

  1. Step 1: Understand PageRank failure impact

    Without updated PageRank, the system cannot assign fresh relevance scores, causing degraded or random ordering.

  2. Step 2: Evaluate other impacts

    Search remains available (not A). Last snapshot is not used if update fails mid-cycle (not B). Indexing continues independently (not D).

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    PageRank failure causes degraded ranking, not outage [check]
Hint: PageRank failure -> degraded ranking, not outage [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard