1.Cluster-Wide Quota Although I have listed it as "Future Work," we all know that "Future Work" sometimes means "I may never do it :)” Implementing that in a leaderless architecture is challenging, particularly because we lack a centralized component(like the Request Router/global admission control in DynamoDB [6]), that provides a global, accurate, and real-time view of the system's load/traffic information.
2.Rejected Alternatives Quota is a well-established feature that has been implemented in many other distributed systems for years, including Apache Kafka[1], HBase[2], Pulsar[3], Hadoop[4], and ZooKeeper[5]. This CEP aims to learn from these systems and adopt their best practices. References: [1] https://docs.confluent.io/kafka/design/quotas.html [2] https://product.hubspot.com/blog/hbase-share-resources [3] https://pulsar-neighborhood.io/articles/apache-pulsar-multi-tenancy-explained/ [4] https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsQuotaAdminGuide.html [5] https://zookeeper.apache.org/doc/r3.9.4/zookeeperQuotas.html [6] https://blog.bytebytego.com/p/a-deep-dive-into-amazon-dynamodb On 2026/03/04 18:14:56 Bernardo Botella wrote: > Thanks for pointing this out Stefan! > > I agree that these proposals are closely related, but I view them as > complementary rather than competing. > > I believe they protect the cluster at two different levels: CEP-61 provides a > flexible layer for multi tenancy where operators can set specific policies to > meet different customer requirements. This would even allow for > 'over-provisioning' quotas while maintaining a safety net that CEP-41 could > provide, protecting nodes from total meltdown if those limits are reached or > if system signals show distress. > > That being said, I think there is value on exploring those two proposals in > parallel. > > On the actual CEP-61, a couple of thoughts: > - I think there would be value on trying to articulate how the cluster wide > quota management will work in the future. I see gossip as one proposed path > forward. I'd love to hear the thoughts of those who know more than I do > around the protocol and the potential alternatives. I am basically trying to > gain the confidence that we actually have a path forward for cluster wide > quota handling, even if it is implemented in a different step of this CEP > delivery. > - Acording to the CEP template, I'd love to see a rejected alternatives > section on the CEP. > > Really curious on what others think! > Bernardo > > > > > On Mar 4, 2026, at 10:31 AM, Štefan Miklošovič <[email protected]> > > wrote: > > > > Hey, > > > > just saying there is also (1) already. There seems to be competing > > proposals in this space we should form some opinions on and proceed > > with the better one or pick the best approaches from both. > > > > (1) > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-41+%28DRAFT%29+Apache+Cassandra+Unified+Rate+Limiter > > > > On Wed, Mar 4, 2026 at 9:47 AM Ling Mao <[email protected]> wrote: > >> > >> I have published CEP-61: Quota Management. You can find the full proposal > >> here: > >> [https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-61%3A+Quota+Management]. > >> I would appreciate any feedback or review comments from the community. > >> > >> On 2026/02/24 09:47:44 Justin Ling Mao wrote: > >>> Hi everyone: > >>> I have created a JIRA ticket:CASSANDRA-21158, regarding a new feature: > >>> Implementing quota management for multi-tenant.You can find the design > >>> document here: > >>> https://docs.google.com/document/d/1BGDjBsuVkuISbN8lqxoZUuGbx0qRhuNA8BAxF48a24kIf > >>> you are interested, please join the discussion. Once we’ve had a > >>> thorough discussion and if the community finds this feature valuable, I > >>> will proceed to create a CEP (Cassandra Enhancement Proposal) and > >>> subsequently submit a PR. > >>> Looking forward to your feedback! > >>> > >>> -------------------------------- > >>> > >>> Best regards > >>> Justin Ling Mao > >>> Beijing,China > >>> > >
