Hi all,

I’m validating an approach around Cassandra-native OpenSearch indexing.

The use case is teams that keep Cassandra as the source of truth but also
need search/query patterns that Cassandra does not support well. Today this
is usually handled through CDC, Kafka, custom dual-writes, Spark jobs,
periodic backfills, or some other external indexing path into
OpenSearch/Elasticsearch.

The problem I’m looking at is operational rather than theoretical:

   - indexing lag
   - missed or duplicated updates
   - reindexing/backfill complexity
   - consistency drift between Cassandra and the search layer
   - recovery after failed consumers or partial writes
   - operational burden of running the sync pipeline

I’m trying to understand whether this is a serious production pain for
Cassandra users, or whether most teams are satisfied with external indexing
pipelines.

For teams running Cassandra with OpenSearch or Elasticsearch downstream:

   1. What architecture are you using today?
   2. Where does the indexing path fail in practice?
   3. Is search freshness/consistency business-critical or just a tolerable
   limitation?
   4. Would a tighter Cassandra-integrated indexing layer be interesting,
   or would that create too much operational risk?
   5. What benchmark, failure-mode test, or compatibility proof would make
   you willing to evaluate an alternative?

I’m looking for blunt technical feedback before overbuilding anything.

Thanks,
Maxim

Reply via email to