Cluster & Data-Model Review
Find out where your cluster actually stands.
Most Cassandra clusters accumulate risk quietly: partitions that grew past their design, tombstones building toward a read-latency cliff, repairs that stopped running the day someone silenced the cron alert. A review surfaces all of it in one pass, ranked by how likely each item is to page you.
What we examine
- Schema vs. access patterns. Every table read against the queries that actually hit it. We look for unbounded partitions, hot partitions, secondary indexes standing in for missing query tables, and
ALLOW FILTERINGin production code paths. - Partition sizing. Measured, not estimated — partition-size histograms from your live cluster, with growth projected against your write rate.
- Tombstones. Delete patterns, TTL usage, and tombstone density per table, mapped against
gc_grace_secondsand repair cadence to flag tables heading for tombstone-overwhelm read failures. - Compaction posture. Strategy per table (STCS, LCS, TWCS, UCS on 5.x) checked against the workload shape — time-series data on size-tiered compaction is a classic slow leak we look for first.
- Repair posture. When repairs last completed, how long they take, and whether the schedule actually fits inside
gc_grace_seconds. - Driver configuration. Consistency levels, retry and speculative-execution policies, token-aware routing, and connection pooling in your client code.
What you get
A written remediation plan, prioritized by production risk: what to fix now, what to schedule, what to leave alone. Each finding names the table or setting, the failure mode it invites, and the concrete change — so your team can execute it without us, or with us by the hour.
How it runs
Reviews are hourly engagements, sized to the cluster in an initial conversation. We work read-only against metrics, logs, schema, and (where you prefer) a screen-shared session with your team — no agent installs, no production writes.