Spring Boot · Java 21 · Docker · Railway

Two services. Two disciplines. Both proven, not asserted.

perf-api chases raw per-core throughput with nothing on the hot path. secure-api spends its CPU budget on auth, RBAC, and distributed rate limiting instead. Every number on this site comes from a committed k6 run or a passing test — see the docs and try it yourself in the playground.

Try the playground View architecture

perf-api

Reactive, non-blocking — built for throughput

WebFlux + Netty — event-loop, non-blocking, no thread-per-request ceiling
Netty native transport (epoll / kqueue) auto-detected, no config
Zero auth, zero DB, zero blocking I/O on the hot path
jackson-module-afterburner for faster (de)serialization
Compression off — CPU spent on requests, not gzip

secure-api

JWT auth, RBAC, distributed rate limiting

JWT access tokens (15m) + rotating opaque refresh tokens (7d)
Refresh-token reuse detection — stolen tokens burn the whole session tree
bcrypt (strength 12) + account lockout after 5 failed logins
RBAC enforced in the Spring Security filter chain
Redis-backed distributed rate limiting — correct across N instances

One repo, two runtimes

Deliberately different stacks per service — the right tool for each job, not one paradigm stretched over both.

Full breakdown

Ready to deploy on Railway — one Dockerfile per service, health-checked, documented.