Projects

Public code · system-design studies

Most of what I've built lives in private repositories — client work, freelance projects, modifications I sold over the years. Below: the one project I keep open on GitHub, plus a notebook of distributed-systems designs I'm reasoning through.

// public on github

one open repo · others private by default

public repo

URL Shortener

Solo

View on GitHub

REST API that shortens URLs, tracks click counts, and caches hot redirects in Redis. Deployed via Terraform to AWS ECS Fargate + RDS, with GitHub Actions building and pushing the image on every merge to main.

  • Terraform provisions ECS Fargate, RDS Postgres, ECR, and IAM — full infra as code
  • CI/CD: GitHub Actions runs tests, builds the image, and pushes to GHCR on every merge
  • Redis cache on the redirect path — cold misses fall back to PostgreSQL and warm the cache
  • Idempotent shortening: same URL in → same code out, atomic click counter
  • Also ported to Python/FastAPI — see shortlink-api below
Java 21Spring BootPostgreSQLRedisTerraformAWS ECSGitHub ActionsDocker

public repo

Shortlink API

Solo

View on GitHub

The Python/FastAPI counterpart to the Java URL Shortener above — same problem, same core decisions (idempotent shortening, Redis-aside caching, atomic click counting), rewritten idiomatically for the async Python stack.

  • Built to confirm the Java version's design choices weren't accidental to Spring Boot
  • Async SQLAlchemy 2.0 + asyncpg, Pydantic HttpUrl validation at the schema boundary
  • Same cache-aside Redis pattern and collision-retry code generation as the Java original
  • 10 tests against an in-memory SQLite engine — no Postgres needed to run the suite
Python 3.12FastAPISQLAlchemy (async)asyncpgRedisDocker

public repo

Kafka Order Pipeline

Solo

View on GitHub

Event-driven order processing: REST API publishes order events to Kafka, a consumer reads and persists them to PostgreSQL. Demonstrates producer/consumer, idempotent processing, and KRaft-mode Kafka.

  • POST /api/orders returns 202 immediately — processing is async via Kafka
  • Consumer deduplicates on order ID before persisting — safe for at-least-once delivery
  • Topic created with 3 partitions, keyed by orderId for ordered per-order processing
  • Kafka running in KRaft mode (no Zookeeper) via Docker Compose
Java 21Spring BootApache KafkaPostgreSQLDocker

public repo

Webhook Dispatcher

Solo

View on GitHub

Spring Boot service that receives events and fans them out to registered HTTP endpoints. Handles delivery failures with exponential-backoff retries and keeps a full audit trail of every attempt.

  • POST /api/events returns 202 immediately — delivery is async via a scheduled worker
  • Exponential backoff: attempt 1 → immediate, 2 → +1 min, 3 → +5 min, then FAILED
  • Every delivery attempt records HTTP response status and body — full audit trail
  • Endpoints can be deactivated without losing event history
Java 21Spring BootPostgreSQLWebClientDocker

public repo

logtriage

Solo

View on GitHub

CLI tool that parses log files and surfaces what actually needs attention — hourly error spikes and recurring patterns, normalized so similar errors with different IPs or IDs count as one incident instead of many.

  • Parses nginx access logs and generic syslog-style lines, keeping unmatched lines instead of dropping them
  • Normalizes messages — strips IPs, UUIDs, and numbers — so scattered errors collapse into one recurring pattern
  • Hourly bucketing surfaces exactly when an incident started
  • 13 tests covering parsing, normalization, and level filtering
Python 3.10+argparseregexpytest

public repo

GitHub Stats ETL

Solo

View on GitHub

Daily ETL pipeline: pulls repo metadata from the GitHub API, cleans it with pandas, and loads it into PostgreSQL as a dated snapshot — builds a time series of star growth and language mix instead of a single point-in-time read.

  • Upserts on (full_name, snapshot_date) — idempotent re-runs, real history on new days
  • Forks excluded from aggregation — a fork's stars belong to the upstream repo, not to the work done on it
  • 10 tests against in-memory SQLite covering pure transform logic and upsert idempotency
  • Scheduled via APScheduler — runs once immediately, then daily at a configured UTC hour
Python 3.12pandasSQLAlchemyPostgreSQLAPSchedulerDocker

public repo

Grocery API

Solo · open source

View on GitHub

Production-shaped NestJS backend: product catalog, cart management, and checkout with real concurrency protection via SELECT FOR UPDATE. Built end-to-end as a take-home assignment.

  • Checkout locks cart + product rows in sorted order to prevent deadlocks and overselling
  • Soft-deleted products stay invisible in catalog but preserve order history snapshots
  • Order cancellation with atomic stock restoration
  • Concurrency stress test: two simultaneous checkouts compete for single-unit stock — exactly one wins
  • One-command boot via Docker Compose; Swagger at /api
NestJSTypeScriptPrismaPostgreSQLDockerSwagger

// system design studies

architectures worked through on paper · not deployed systems

1.2M events/min

Realtime Event Processing Platform

01

Horizontally scalable event pipeline ingesting millions of events per minute with sub-second end-to-end latency.

// design targets

throughput

1.2M ev/min

p95 latency

180 ms

uptime

99.95%

consumer lag

< 1.5 s

  • Partition-aware consumer groups with cooperative rebalancing
  • At-least-once delivery with idempotent sinks (Redis dedupe keys)
  • Backpressure via reactive streams; lag-based autoscaling
KafkaSpring BootRedisPostgreSQLKubernetes
design study · not deployed
99.97% delivery SLO

Distributed Notification System

02

Multi-channel notification fabric (push, email, SMS) with delivery guarantees, per-tenant routing, and provider failover.

// design targets

delivery

99.97%

p99 dispatch

240 ms

tenants

1,800+

retry rate

0.4%

  • Tenant-aware fan-out with priority queues
  • Exponential retry + dead-letter policies per channel
  • Active/active provider failover with health-weighted routing
GoNATSPostgresgRPC
design study · not deployed
p99 < 180ms

Payment Gateway Infrastructure

03

PCI-aligned payment orchestration with deterministic settlement, idempotent ingress, and pluggable PSP adapters.

// design targets

p99

178 ms

auth success

98.6%

reconciliation

T+0

PCI scope

SAQ-D

  • Idempotency keys with replay protection
  • Encrypted at rest (KMS) and in transit (mTLS)
  • Adapter pattern for PSPs — Stripe, Adyen, in-house
JavaSpring BootKafkaVaultTerraform
design study · not deployed
120k concurrent

WebSocket Messaging Service

04

Low-latency bidirectional messaging with presence, typing indicators, and ordered delivery across regions.

// design targets

connections

120k

p50 RTT

38 ms

msg/s peak

44k

regions

4

  • Sticky routing via consistent-hash on session ID
  • Cross-region pub/sub fanout through Redis streams
  • Per-room rate limits and abuse detection at edge
Node.jsRedisWebSocketNginx
design study · not deployed
300+ services

Infrastructure Monitoring Dashboard

05

Unified observability console correlating metrics, logs, and traces across heterogeneous infrastructure.

// design targets

services

312

alerts/day

~140

noise reduction

−68%

MTTA

3.2 min

  • Service-map auto-discovery from OTel resource attributes
  • Alert deduplication and incident-grouping heuristics
  • SLO budgets visible per service and per team
PrometheusGrafanaOpenTelemetryNext.js
design study · not deployed
p95 < 12ms

High-load API Gateway

06

Edge gateway with token-aware routing, fine-grained rate limiting, and policy enforcement via OPA.

// design targets

p95 overhead

11 ms

RPS peak

62k

policy eval

0.6 ms

cache hit

94%

  • JWT/JWS validation with JWKS caching
  • Per-route and per-tenant quotas (token bucket)
  • Canary and shadow traffic via header-based routing
EnvoyGoRedisOPA
design study · not deployed