Case study · Systems & Infrastructure
DurableGo
A small, inspectable durable-workflow engine
The problem
Background work is easy to start and hard to finish correctly: workers crash mid-execution, retries double-apply side effects, and an old worker resuming after its lease was reclaimed can silently overwrite newer state. DurableGo makes those failure modes visible and provably handled.
What I built
Workflow engine
An application starts a workflow of dependency-aware activities. DurableGo persists the workflow, leases ready activities to workers, records every state transition, and uses fencing tokens to stop an older worker from overwriting a newer claim.
Lease + fencing-token claims
Every claim carries a lease owner and a monotonically increasing fencing token. Stale heartbeats, completions and failures are rejected after a newer claim; the scheduler returns abandoned or retry-pending work to the ready queue.
Idempotent starts
Reusing a namespace and idempotency key returns the original workflow instead of creating a duplicate.
Read-only proof dashboard
A Next.js console distinguishes deterministic Demo evidence from an unavailable, empty, partial or populated Live API response — it never replaces an unavailable response with fixture data.
Engineering decisions
At-least-once, stated plainly
Activities execute at least once, not exactly once. A side effect can be attempted again after a crash, so applications supply their own idempotency key for an external charge, email or write. The engine's job is to make its own state transitions safe and explainable.
PostgreSQL as the persistence contract
Workflow state, activity leases, idempotency keys and event history all live in PostgreSQL, so every guarantee is traceable from database state through ordered events into the API.
Failure scenes as the product
Automated scenes SIGKILL workers mid-execution and drive crash recovery, stale fencing, duplicate starts and retry exhaustion — the proof is the point, not an afterthought.
Testing & CI
go test ./... with testcontainers; race detector runs under CGO_ENABLED=1 with a C toolchain via the Makefile. Deployed live as a single all-in-one container (API, scheduler, two workers, demo traffic driver) on free-tier hosting with Neon Postgres, dashboard on Vercel.
Screenshots
Operations dashboard
Execution totals, ready work, active leases and failure scenes for crash recovery, stale fencing, duplicate starts and retry exhaustion
Go / PostgreSQL / testcontainers / Next.js