tobira

GitHubconsole workspace

high performance distributed rate limiting.

a high-concurrency rate limiter cluster built in go, designed to coordinate request policies across nodes using a peer-to-peer udp gossip protocol. leverages convergent g-counters to track rate limits without central redis databases or single points of failure.

what is this project? most rate limiters count user requests by saving them in a single central database like redis. if that database crashes, the entire application breaks. tobira works differently: multiple servers talk directly to each other to share request counts. if one server goes down, the others continue running and sharing the load.

detailed information on how the go code is designed, how to build the cluster, and how to run tests can be found in the project documentation.

read the full implementation details in readme.md
connect port:
status:
disconnected
bash - tobira-node

interactive limiter workspace

simulate latency spikes, network partitions, or node mutations live

throughput

0

total calls

allowed

0.0%

0 calls

blocked

0.0%

0 429 requests

latency

0.00ms

evaluation avg

cluster topology visualizer

real-time gossip exchange particles & failure status

healthy
suspect
dead
DRAG NODES TO ADJUST FORCE-DIRECTED LAYOUT POSITION

failure simulator

simulate partition splits by shutting off udp heartbeats or gossip merges

algorithmfixed window

swap the active rate limiting algorithm on this node in real time

node request log

listening for rate limiting traffic...

tobira instruction

1

start the cluster

run sh scripts/demo.sh in your terminal. this orchestrates 4 peered docker containers and spins up the next.js console dashboard.

2

generate client traffic

the demo script launches tobira-load to dispatch background http traffic across nodes at a rate of 50 rps. you will see allowed/denied metrics fluctuate live.

3

mute gossip / partitions

mute gossip sync or heartbeats using the simulator buttons. watch the nodes turn to suspect (yellow) or dead (red) as failure detectors report state divergence.

4

crash and recover nodes

crash nodes to test failover routing. the cluster automatically detects dead peers, re-routes state updates, and merges g-counters back together when the node recovers.

crdt g-counter state matrix

live convergent vector state across all nodes

merges:0

no cluster state data synced yet

send requests via `tobira-load` or `curl` to populate g-counters

cluster requests throughput

live rate of http 200 (allowed) vs http 429 (blocked)

evaluation latency

average time spent per rate limiting decision (ms)