Both writes were in one batch. Why did a reader see only one?

Atomic completion is not simultaneous visibility

A logged multi-partition batch is designed to make the batch's mutations eventually get applied as a unit of intended work despite coordinator failure, under the storage system's recovery assumptions. It is not a general-purpose isolated transaction in which other clients can only see an all-old or all-new snapshot across partitions.

Cassandra's documented batch semantics distinguish single-partition isolation from multi-partition batch behavior. The documentation explicitly states that other clients may read early mutations while the rest of a multi-partition batch is still being applied. Cassandra BATCH

That is the root of the scenario. A successful mechanism for not forgetting remaining writes is not automatically a mechanism for presenting an atomic read snapshot across those writes.

Walk through a coordinator failure

Suppose the application submits three mutations:

A  orders_by_id           o481 -> SHIPPED
B  orders_by_customer     o481 -> SHIPPED
C  open_orders_by_region  remove o481

The coordinator records the batch obligation in the batchlog as appropriate. It sends work toward the relevant replicas. Mutation A becomes visible to a read, while mutation B has not yet become visible under the reader's consistency and timing. The coordinator fails before every target has completed.

A logged batch provides information needed to continue applying unfinished mutations, assuming its recovery and replicas remain available. But a reader checking A and B during the interval can observe different representations.

A request timeout introduces further uncertainty. It does not prove the batch failed or that none of its effects happened. The client should investigate a stable order version or retry safely according to the write contract, not issue a new unrelated order transition.

Make one order fact authoritative

For this scenario I would identify the one record that owns the order's business state. orders_by_id could serve that role if its update path enforces allowed transitions and the required concurrency behavior.

orders_by_customer and open_orders_by_region would then be derived views, deliberately allowed to lag within a visible freshness contract. If a shipping worker needs to decide whether shipment is authorized, it consults the authoritative business state and any payment evidence required by the invariant. It cannot rely on the potentially stale regional list alone.

The key is not a table name. It is an explicit ownership rule: which service and record decide whether an order has moved from PAID to SHIPPED, and under what conditional or coordinated write protocol?

QUORUM acknowledgments do not make arbitrary cross-partition rows one isolated transaction. A conditional transition needs a separate supported coordination protocol.

What if business really needs all three views to agree?

First challenge the requirement. A shipping worker may need one strong decision, while a dashboard can tolerate temporary lag. Requiring three denormalized query tables to become visible simultaneously may be an unnecessary cost that fights the database model.

If a consumer must read a coherent set, one approach writes a shared version or generation marker and makes the reader pin a committed generation after the required records exist. That protocol needs immutable, version-addressed records, a safely read committed marker, retention, and reads that establish every required version is available. Seeing the marker at one replica does not prove another replica can return all referenced rows; missing or older versions must make the read wait, retry or fail rather than return a partial generation. That is a protocol the application must carefully implement and validate. It is not supplied merely by wrapping writes in BEGIN BATCH.

Another approach routes the coherence-critical query through one authoritative record and treats the other tables as materialized projections. That sacrifices some lookup convenience but simplifies correctness.

A full transactional datastore supporting the required multi-record snapshot semantics is also an option when the workload fundamentally demands them. It would be a reasonable architectural tradeoff, not an admission that every Cassandra model is unsuitable.

Logged batches have a real cost

A tempting performance idea is to place 10,000 unrelated writes in one giant batch to reduce client calls. That is often a poor Cassandra design. Cross-partition logged batches add coordinator and batchlog work, and they do not turn unrelated partition writes into one high-throughput sequential operation.

DataStax's guidance specifically warns that multi-partition batches can worsen latency and throughput and recommends them for limited cases where atomic application is the requirement, not as a bulk-loading optimization. Batching inserts and updates

For bulk ingestion, independent asynchronous writes with bounded concurrency and appropriate routing may be more efficient, as long as the business semantics permit independent success and recovery.

How should the system detect and repair drift?

The architecture needs a way to compare projections with the authoritative order state. A background reconciliation job can scan recent transitions and detect missing or outdated customer and regional views. It should repair by stable order identity and version, rejecting an older repair that would overwrite a newer state.

Monitor unresolved projection lag, consistency of representative samples, failed mutation categories and batchlog pressure. A successful batch response alone cannot demonstrate that every query representation was observed simultaneously.

If three screens may disagree for a few seconds, document the lag and repair it. If a cross-table contradiction would authorize an irreversible side effect, move that decision to one enforced authority or a database protocol that actually supplies the required snapshot and conditional semantics. Do not stretch the meaning of “atomic” until it conceals the difference.