Clearbay

Financial workflows that stay correct under retries.

Live · 10 integration tests · Updated 2026

Java 21 · Spring Boot · PostgreSQL · Redis · MCP

Hosted on Render. The first open may take up to about 60 seconds; the proof below remains available immediately.

Context: Independent public reimplementation · 2026
My role: Designer and sole engineer
Team: Solo build
Evidence: 10 integration tests · production-shaped contracts

POST /api/v1/waves/482/release · loser

{
  "type": "about:blank",
  "title": "Conflict",
  "status": 409,
  "detail": "record was updated by another request"
}

Warehouse SaaS shares one database across customers. A retry, a spoofed header, or a cache key without a tenant prefix is enough to charge twice or leak inventory.

Failure

Client sends another tenant in a header.
Ignored. TenantContext is bound from the token only.
Invoice generate is retried.
Idempotent on (tenant, period). Same invoice, no double charge.
Two ops release the same wave.
Optimistic lock on version. Loser gets 409; inventory is not double-reserved.
Worker starts before the job row commits.
afterCommit callback. The insert is visible first.
MCP call includes extra JSON fields.
Unknown fields rejected before execution.

Inspect

Live Open product ↗

Source GitHub ↗

Wake time Allow up to about 60 seconds on the first request.

What I would improve next

Replace the demo token issuer with an external identity provider and rotate signing keys through managed secrets.
Load-test tenant-scoped PostgreSQL and Redis paths, then publish latency and isolation evidence.
Move jobs and side effects to a durable outbox with distributed claims, heartbeats, and fencing.