Event-Driven Emergency Response
RescueFlow
RescueFlow is a portfolio system for studying reliable emergency coordination with synthetic incidents: deterministic dispatch, resource reservation, notifications, and an immutable operational timeline.
View source on GitHubContext
Problem, constraints, and my role
A response workflow must coordinate several state changes without double-booking resources, losing work between writes and messages, or hiding partial failure from operators.
Constraints
- The verified runtime uses an in-process broker and local store rather than claiming live distributed infrastructure.
- At-least-once delivery requires consumers to be idempotent and retries to be bounded.
- Concurrent reservations must produce one winner without double-booking a resource.
My role
I designed and implemented the synthetic workflow, service boundaries, event contracts, reliability patterns, API surface, operator dashboard, and automated verification.
Project media
The system in view
Interface studies and working demonstrations from the project.
Architecture note
Verified local event workflow
A Go REST API coordinates the workflow core, transactional local outbox, local broker and store, while WebSocket events keep the React operator interface current.
Engineering decisions
The choices that shaped the work
Make delivery semantics explicit
A transactional local outbox, idempotent consumers, bounded retries, and dead-letter metadata model at-least-once delivery without hiding duplicate work.
Protect scarce resources under concurrency
Optimistic concurrency prevents double booking; race-enabled tests verify that competing reservations produce exactly one winner.
Compensate workflow failure deliberately
Saga compensation handles rejection and reservation failure, while notification retries remain isolated so they do not roll back an otherwise valid assignment.
Result & reflection
What the work produced
A live HTTP smoke test moved a synthetic incident to ASSIGNED with four immutable timeline entries, zero outbox backlog, and zero dead letters; formatting, vet, race-enabled backend tests, frontend tests, and production builds also passed.
What stayed with me
PostgreSQL, Kafka, Redis, Docker, Kubernetes, OpenTelemetry, and load-testing assets are designed and checked in, but they are not wired into the verified runtime; persistent adapters, live distributed integration, deployment, and benchmark results remain future work.
- Go
- REST
- WebSockets
- React
- TypeScript
- Prometheus
- OpenAPI
- AsyncAPI