Why this matters
- VaultCommerce ingests millions of clickstream and order-status events per day; writing every event to Postgres would saturate the primary.
- Cassandra's tunable consistency and append-friendly storage fit time-series and audit logs.
- Interviews test whether you can explain partition keys, clustering columns, and why
SELECT *without a partition key is a cluster-wide scan.
Rows, partitions, and clustering
Cassandra tables are sorted maps: a partition key routes a row to a node; clustering columns order rows inside that partition.
Cassandra vocabulary
- Partition key — determines which node stores the data; keep partitions under ~100 MB.
- Clustering columns — sort rows within a partition (e.g. event time descending).
- Column family — logical grouping of columns; think wide rows, not skinny SQL tables.
- Tunable consistency — per-query
ONE,QUORUM, orALLdepending on freshness needs.
CREATE TABLE order_events (
order_id UUID,
event_time TIMESTAMP,
event_type TEXT,
payload TEXT,
PRIMARY KEY (order_id, event_time)
) WITH CLUSTERING ORDER BY (event_time DESC);
VaultCommerce's order timeline query — "show status history for order X" — hits one partition keyed by order_id. No cross-partition join required.
Query-first table design
In Cassandra you create one table per query pattern. VaultCommerce maintains separate tables for "events by order" and "events by customer per day" because a single flexible table cannot serve both efficiently.
-- Access pattern: daily funnel per customer
CREATE TABLE customer_daily_events (
customer_id UUID,
day DATE,
event_time TIMESTAMP,
event_type TEXT,
PRIMARY KEY ((customer_id, day), event_time)
);
The double parentheses ((customer_id, day), event_time) make (customer_id, day) the partition key — all events for one customer on one day live together.
Write path and compaction
Cassandra appends writes to a commit log and memtable, then flushes immutable SSTables. Compaction merges files in the background. This design favours sequential writes over in-place updates — ideal for append-only event logs, painful for frequently updated counters unless you batch them.
| Aspect | Postgres (VaultCommerce orders) | Cassandra (VaultCommerce events) |
|---|---|---|
| Sweet spot | ACID checkout, joins | High-volume append-only writes |
| Query model | Ad hoc SQL | Partition-key lookups only |
| Scaling | Vertical + read replicas | Linear horizontal write scale |
| Consistency | Strong per transaction | Tunable per read/write |
Sweet spot
Postgres (VaultCommerce orders)ACID checkout, joinsCassandra (VaultCommerce events)High-volume append-only writesQuery model
Postgres (VaultCommerce orders)Ad hoc SQLCassandra (VaultCommerce events)Partition-key lookups onlyScaling
Postgres (VaultCommerce orders)Vertical + read replicasCassandra (VaultCommerce events)Linear horizontal write scaleConsistency
Postgres (VaultCommerce orders)Strong per transactionCassandra (VaultCommerce events)Tunable per read/write
Operational trade-offs
Repairs, tombstones, and hot partitions are real production concerns. A celebrity product launch that funnels all traffic through one product_id partition will bottleneck a single node. VaultCommerce salts hot keys or buckets high-cardinality IDs across synthetic suffixes.
Quick recall
Everything you need if you only revisit this box.
- Cassandra partitions data by a key you choose — design tables around queries, not entities.
- Clustering columns sort rows inside a partition for range reads.
- VaultCommerce uses Cassandra for append-only order and clickstream events.
- Avoid hot partitions; salt or bucket keys that concentrate traffic.
- Tunable consistency trades freshness for availability on every read and write.
Test yourself
Answer these before moving on — recall is what makes it stick.