[henschwartz]

Summary

• Adds What?/Why? proposal for Distributed In-Memory Counters (praxis#155) under epic #163.
• Stages single-instance atomic incr/decr + TTL before optional peer replication; Non-Goals separate #99, token RL, L4 limits, and Overload Manager.
• No How? section (follow-up after direction is accepted).

Test plan

• Local proposal-check

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: Repository: praxis-proxy/coderabbit/.coderabbit.yaml
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: e8eadef8-6164-4f5e-aa62-1b9dc6102ef1

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[alexsnaps]

I seem to see that much of this overlaps with ENH-99, no?

New seem to be:

1. Peer replication with no central store. which ENH-99 puts gossip/CRDT state out of scope. Tho the "or shared backend" half is just 00099's Valkey backend too, no?
2. Rates, not just counts. I think you want control over eviction and support for gauges?
3. Typed keys (IP, integer).
4. Max-entries cap.
5. New consumers: abuse detection and routing conditions. These would read counters, yes? Tho this currently has no design for how a condition reads the store, does it?

Which I think could be pretty much all be accounted for in ENH-99, no? Possibly not for 5?
But if so, do we need to spec that actually?

[alexsnaps]

@maleck13 I think there is much overlap with your work around making limitador's crate consumable in PPE

[henschwartz]

@alexsnaps Thanks — your read matches how we're looking at this now.

After comparing this What?/Why? draft to ENH-00099 (and the adjacent limitador work in policy#178), most of praxis#155 looks covered already:

• local in-memory + shared Valkey-backed counters / rate-limit domain APIs
• bounds, TTL, eviction, metrics
• multi-replica via a central store (not gossip/CRDT)

What might still be distinct for #155 (if anything) seems narrow:

1. Stick-table-style metric families / rates (not only raw counts), typed keys as a first-class contract
2. A read path for abuse detection and routing conditions (your point 5)
3. Peer replication without a central store — which looks out of line with 00099's Valkey direction

should we keep praxis#155 / this proposal as a thin follow-on for (1)/(2) only, or close/withdraw it and fold any remaining bits into ENH-00099 (and leave rate-limit policy plugins to the limitador track)?

Happy to reshape or close this PR once that's clear — holding edits until then.

[redhat-chai-bot]

Adversarial Review — docs(proposals): distributed in-memory counters

Pure proposal document. Well-structured design for distributed counter sharing.

Verdict: Recommend merge.

---

AI-generated. Review for accuracy.