■FIG. A.2 · Self project · Go network data plane
GoRESP Edge Cache
This project exists to answer one question honestly: what does a real Redis-compatible edge cache need once you refuse to hand the hard parts to a library? The answer, in Go, is a hand-rolled RESP-2 parser, a TTL’d LRU store shared with token-bucket rate limiting, an append-only file whose durability is proven by killing the process mid-write, replication with a documented consistency window, and a load balancer that ejects dead backends without anyone noticing. Below, each subsystem has a live model running its actual algorithm.
— console idle —
store · capacity 4 · clock 0 ms
| empty | try: SET a 1 PX 600 · SET b 2 · GET a … |
THE CACHE ENGINE
The parser speaks RESP-2 over a goroutine-per-connection TCP server. One store does double duty: it serves the TTL’d LRU cache and supplies the token-bucket rate limiter, which is how the system pays for itself at the edge. Expiry is lazy — keys are checked on access, not by a sweeper tax on every tick.
DURABILITY, PROVEN BY MURDER
The AOF appends each acknowledged write; fsync policy is runtime-tunable (always / everysec / no), and the trade-offs are real: only always gives you zero acknowledged-write loss, and the fuzz harness is what proves it — SIGKILL during writes, replay on restart, torn trailing commands discarded, then a diff of acknowledged keys. Replication is async primary-replica with lag metrics and scripted failover, and the stale-read window is documented rather than wished away.
BALANCING
Round-robin and least-outstanding strategies sit behind active/passive health checks; failed backends are ejected, and chaos kills of live backends are absorbed invisibly. The lab above runs the same ejection arithmetic — in the model, two consecutive missed ticks trip ejection.
Prev: FIG. A.1 · qlabaqua.comNext: FIG. A.3 · Deaf Audio Assistant