Cassandra's post-4.0 roadmap separates proposals from releases

Cassandra's return to feature development raises a question about how much responsibility belongs inside the database. Some proposals aim to contain a damaging request before it affects unrelated work. Others aim to move coordination across multiple keys into the database itself. Both respond to operational complexity, but they make different promises and require different evidence before users can depend on them.

The October 26 roadmap reports that the feature freeze used to stabilize 4.0 has ended. The Cassandra Enhancement Process is the preferred route for broad or disruptive changes. Its account identifies approved work in development, including simulations, partition denylisting and general-purpose transactions. It separately identifies Storage Attached Indexing as approaching a vote. At this stage of development, those statuses do not mean the capabilities are all available in the latest release.

I find the distinction useful because Cassandra should enter an architecture for a requirement it can actually satisfy. Its active-active capabilities are attractive, but a roadmap is not an implementation contract. The proposals let users understand the direction of development while retaining a boundary between an intended mechanism and a released behavior.

Denylisting contains known partition-level harm

An early CEP-13 revision from August 16 explains the motivation for partition denylisting. Reads for particular keys can impose enough work to affect the node and unrelated queries. The examples include partitions with many live cells or tombstones, and heavily written partitions spread across SSTables that have not yet been compacted.

The proposed facility lets an operator identify keys whose reads should be disallowed. Its intended role is containment while other optimizations address the underlying behavior. That distinction matters because preventing a read does not reduce the amount of data in the partition or compact the SSTables containing it. It changes whether the database admits the specified request.

Automatic detection is an explicit non-goal in this revision. The operator supplies the keys. The proposal therefore does not describe a general anomaly detector that discovers damaging traffic and decides which data to block. It supplies a control that depends on a prior operational decision about specific partition keys.

That scope also separates the feature from general admission control. A denylist identifies particular data keys. It does not describe every possible source of resource pressure or infer an application's relative priorities. A reader can assess the proposal more accurately by retaining the unit it controls and the actor who selects it.

The early interface design includes a cache-refresh method on StorageServiceMBean and a proposed nodetool command. It discusses a sidecar API for adding keys and an alternative nodetool approach. The alternative has a qualification that a command issued against one node could affect the whole cluster. This is an interface question within the proposal, rather than a reason to assume every proposed command has shipped.

The compatibility section says the feature works as expected once every node has upgraded to a version containing it. That condition is consistent with a distributed policy whose enforcement must exist wherever a request can arrive. The proposed test plan also includes latency measurements with many denied keys and large partitions. Maintaining a denylist adds a lookup and data structure whose behavior deserves its own assessment.

Transactions change the scope of application coordination

The initial September 5 CEP-15 design addresses another boundary. Its motivation is the effort users expend to change state consistently across multiple partitions. The proposal calls for general-purpose transactions over arbitrary keys, with strict-serializable isolation and no new scalability bottleneck.

Accord is the proposed leaderless timestamp protocol. The design separates agreeing on an execution timestamp from waiting for the earlier conflicting transactions needed to evaluate reads. A coordinator obtains responses from participating shards and uses those responses to calculate the update. Replicas must respect relevant dependencies before applying results.

That is a larger change in database responsibility than rejecting selected partition reads. The transaction proposal aims to replace application-level coordination for operations within its eventual scope. Its initial revision proposes a standalone library and associated integration work. It explicitly describes the prototype as incomplete and not ready for production use.

By October, the roadmap reports that the transaction proposal has been approved. Approval changes its project status, but the roadmap still describes implementation as future work. Keeping those statements together avoids treating acceptance of a design as delivery of the corresponding transactional guarantees. The initial protocol description supplies mechanisms to discuss, while a released integration must eventually establish their actual behavior in Cassandra.

I am interested in this direction because transaction coordination and active-active operation need to be considered together. A proposed one-wide-area-round-trip goal is useful only with its assumptions about clocks, dependencies and failures intact. The early design describes those assumptions, including a reorder buffer and a fast-path electorate, rather than presenting the latency objective as an application benchmark.

Proposal status provides an operational boundary

The roadmap also places testing work beside the feature proposals. A cluster and code simulator is intended to permit repeatable, pseudorandom exploration of operations and correctness. That provides a context for the transaction and Paxos work discussed in the same update. The article reports development priorities, not a guarantee that a simulator has already established every property of the planned changes.

This process gives different readers concrete questions. An operator assessing denylisting can examine who chooses the keys and when enforcement becomes available across the cluster. An application designer assessing transactions can examine the proposed key scope and isolation requirement. Both still need a released version before substituting the proposal for current behavior.

The post-4.0 roadmap therefore supports planning at the level of design and project status. Partition denylisting offers a proposed response to known harmful reads, with operator-selected keys and full-cluster adoption as conditions. General-purpose transactions have a broader integration task, including timestamp agreement and dependency-respecting execution across participating shards.