Featured Project

EventMesh

A small distributed order-processing system built to show how reliable messaging, retries, and observability fit together in practice, using "place an order" as a simple stand-in domain. An order service writes through a transactional Postgres outbox, so the business row and the event it produces can never disagree about whether the write happened. A relay ships pending events onto NATS JetStream with at-least-once delivery; a notifier service consumes them exactly once via a two-phase Redis dedup, so a redelivered message never sends a second email. Events that fail permanently land in a dead-letter stream instead of being dropped, with a CLI tool to replay them once the underlying issue is fixed.

• Distributed tracing carries a single request's trace context from the HTTP call, through the outbox row, across the relay's async publish, over NATS message headers, into the consumer — one connected trace in Jaeger, not fragments.
• Redis-backed rate limiting shared across instances via GCRA, fails open if Redis is unreachable so its own outage can't take the API down with it.
• Postgres-backed integration tests, plus a k6 load test used to chase down a real throughput plateau: CPU was idle and pprof showed no hotspot, which pointed at requests queuing for a Postgres connection rather than a code bottleneck. Raising the pool size took throughput from 7,900 to 12,700 requests/second (+60%) and cut p95 latency from 44ms to 31ms, with no code change.
• Reached v1.0.0 with a small deliberate API refactor: the broker's publish contract takes an extensible message object instead of positional parameters, so new metadata can be added later without breaking every call site.