Cassandra — Portfolio Projects
Build these projects to demonstrate real skills to employers. Each project is designed to be interview-worthy — something you can walk through in detail.
Project 1: Query-Driven Schema Design for a Real Domain
Level: Beginner-Intermediate | Time: 2 days
Design a Cassandra schema for a realistic domain (a messaging app, an IoT sensor platform, or an activity feed) starting from the queries you need to serve, not from an ER diagram — this is the core discipline Cassandra schema design actually requires.
Steps
(sensor_id, date) rather than sensor_id alone) for any naturally unbounded partition
ALLOW FILTERING)
Skills Demonstrated
GitHub Repo Name
cassandra-query-driven-schema
---
Project 2: Time-Series Ingestion with TTL and Compaction Tuning
Level: Intermediate | Time: 2-3 days
Build a realistic time-series ingestion pipeline (IoT sensor readings or application metrics) and tune it the way a real production Cassandra deployment would be tuned.
Steps
PRIMARY KEY ((device_id, day), reading_time)) and set an appropriate default_time_to_live for your domain's real retention needs
TimeWindowCompactionStrategy on the table and explain in your README why it's the right choice for time-series + TTL data specifically, versus the default SizeTieredCompactionStrategy
TRACING ON that the query is hitting a bounded number of partitions/SSTables, not scanning broadly
Skills Demonstrated
TRACING, not just assuming it's correct
GitHub Repo Name
cassandra-timeseries-ingestion
---
Project 3: Multi-Node Cluster with Consistency Level Tradeoffs
Level: Advanced | Time: 3-4 days
Stand up a real multi-node Cassandra cluster (Docker Compose is fine) and actually exercise consistency-level tradeoffs, not just configure a single node.
Steps
replication_factor: 3 and confirm via nodetool status and nodetool ring that data is actually distributed across nodes
CONSISTENCY ONE and immediately read with CONSISTENCY ONE from a different node — deliberately trigger and document a case where you read stale data
CONSISTENCY QUORUM for both reads and writes, and confirm you no longer see the stale-read behavior — explain in your README why R + W > RF guarantees this
docker stop) and confirm which consistency levels still succeed and which start failing — this demonstrates the real availability/consistency tradeoff, not just the theory
nodetool repair after bringing the node back and document what it actually does
Skills Demonstrated
nodetool status/ring/repair)
GitHub Repo Name
cassandra-consistency-cluster-lab
---
Tips for Great Cassandra Projects
Design from queries, not entities. A schema that looks like a normalized relational design (with implied joins) is the single most common sign a Cassandra project wasn't actually designed the way Cassandra requires.
Show real distributed behavior, not just single-node CRUD. nodetool status, a genuine multi-node cluster, and a real consistency-level tradeoff demonstrated (not just described) are what separate a Cassandra project from "I ran some CQL commands."
Cassandra has no JOINs and no foreign keys — don't reach for SQL-shaped solutions. If a project design implies a JOIN across tables, that's a signal the schema needs to be denormalized differently, not that Cassandra is missing a feature.