Redis Bloom — Thang Nguyen

Start at the socket.

Redis Bloom is a Redis-style in-memory database built from scratch in Go. The implementation spans RESP parsing, command execution, key expiration, sets, and sorted sets, alongside the TCP server that connects clients to those operations.

The project brings networking and data structures into the same implementation: an event-driven connection model on one side, and purpose-built structures for storing and querying data on the other.

MEDIA SLOT / 01

FIG. 01 — Redis Bloom terminal / project overviewILLUSTRATION · SOURCE MEDIA TO ADD

One event loop. Two operating systems.

ENGINEERING DECISION

Use an event-driven TCP server

The server uses a single-threaded event loop, with Linux epoll and macOS kqueue. Its performance was compared locally against a goroutine-per-connection TCP baseline.

WORKFLOW COMPARISON / SIMPLIFIED

One connection model. Two approaches.

BASELINEGoroutine per TCP connection

Local comparison implementation

REDIS BLOOMSingle-threaded event loop

epoll on Linux / kqueue on macOS

The local benchmark compares a goroutine-per-connection TCP baseline with Redis Bloom’s single-threaded, event-driven server. This is a connection-model comparison, not a complete deployment diagram. Redis Bloom is a personal project.

CONSTRAINT / BOUNDARY

Platform-specific networking

The implementation uses operating-system-specific event notification APIs. The supplied material does not establish support beyond Linux and macOS, or provide production workload measurements.

Data structures with a job to do.

Sorted-set operations use a custom B+ tree. Bloom filters support approximate membership checks, while Count-Min Sketches estimate frequencies using MurmurHash3.

MEDIA SLOT / 02

FIG. 02 — Data structures / implementation detailILLUSTRATION · SOURCE MEDIA TO ADD

Measure the connection model.

+24%

higher throughput

MEASUREMENT CONTEXT

Resume-reported local benchmark against a goroutine-per-connection TCP baseline. Hardware, request mix, concurrency, dataset size, and run count were not supplied.

−25%

lower average latency

MEASUREMENT CONTEXT

Reported for the same local comparison. Average latency is not a tail-latency measure; p95 and p99 results were not supplied.

BENCHMARK METHODOLOGY & LIMITATIONS

These are local comparison results, not a claim of superiority over Redis or a production capacity estimate. Benchmark scripts and raw output have not yet been verified. A reproducible report should record the environment, workload, baseline commit, and repeated measurements.

MEDIA SLOT / 03

FIG. 03 — Benchmark output / results to addILLUSTRATION · SOURCE MEDIA TO ADD

REFLECTION / NEXT STEPS

What to investigate next

A useful next step is a reproducible benchmark suite covering throughput, average and tail latency, and memory consumption across connection counts. This is proposed follow-up work, not a completed result.