Sanguine

Inspiration

In January 2026 the American Red Cross declared a severe blood shortage after national supply fell about 35 percent in a single month. Some hospitals were down to less than a two day reserve.

What struck me is that this is usually not a donation problem. The right unit often already exists somewhere in the network. It just gets promised to two hospitals at once, and one patient is left without blood. The failure is coordination, not supply. No patient should be lost because two facilities unknowingly claimed the same bag at the same moment.

Sanguine exists to make that specific failure impossible.

What it does

Sanguine is a shared inventory reservation and surge coordination layer for blood centers, hospital supply teams, and regional coordinators.

A facility requests blood in plain English, such as "we need 4 units of A negative within 72 hours." When two facilities request the same scarce unit at the same instant, Sanguine confirms exactly one reservation, instantly reroutes the other request to the next compatible unit, and records every decision in an audit ready log. The headline number, "double promised units," stays at zero.

Key capabilities:

• Live allocation console with a guided demo and a one click demand surge.
• Sanguine vs legacy toggle that fires the same surge at a correct engine and a deliberately wrong one, so viewers can watch the legacy path double promise a unit and Sanguine refuse to.
• FEFO allocation that prefers the soonest to expire compatible unit, which reduces waste, plus automatic refusal of expired units.
• Emergency vs standard tiers, where emergency requests draw only pre tested, available now stock under a tight window.
• Regional network overview with network wide analytics, per center utilization, expiry risk, and center discovery, showing which center can fulfill a request ranked by stock and ETA.
• Append only custody log so every reservation, reroute, release, and expiration is replayable.

How I built it

The front end is Next.js on Vercel. The database is Amazon Aurora DSQL, chosen because the core requirement is a correctness guarantee under concurrency: no unit may ever be allocated twice, even under a write storm. That is a distributed strong consistency problem, which is exactly what Aurora DSQL is for. The natural language intake agent is Claude Haiku 4.5 on Amazon Bedrock, with a deterministic regex parser as a fallback.

Aurora DSQL is always strongly consistent and uses optimistic concurrency control rather than locks. It has no sequences, no foreign keys, and no SELECT ... FOR UPDATE. So instead of locking, every claim routes through one authoritative, version checked row plus a primary key on the allocations table:

-- Optimistic claim on the authoritative inventory row.
-- Two racers both pass this in their own snapshot...
UPDATE blood_units
   SET status = 'held', held_by_request = :req, version = version + 1
 WHERE id = :unit AND version = :seen_version AND status = 'available';

INSERT INTO allocations (unit_id, request_id);  -- unit_id is PRIMARY KEY
COMMIT;
-- ...but only one COMMIT wins. The other gets a serialization failure
-- (SQLSTATE 40001), retries, finds the unit taken, and reroutes via FEFO.

The demand surge uses a small barrier so every racing transaction reads the contested unit before any of them commits, which makes the collision land on every run. Discovery and the network overview are pure DSQL aggregation queries. The UI polls a state endpoint about once a second, which looks live on camera at a fraction of the WebSocket effort.

Challenges I ran into

The biggest challenge was that Aurora DSQL is not vanilla Postgres. I had to rethink the whole concurrency model around optimistic concurrency instead of pessimistic locks, replace sequences with UUIDs, and enforce referential integrity in the application.

The subtle one: I could not make DSQL "naive" by removing locks, because it is always strongly consistent. If two transactions write the same row, one fails at commit no matter how sloppy the code. So to demonstrate the failure honestly, the legacy path sidesteps the authoritative row entirely and writes its own promise to a separate, unconstrained table. Two such promises touch disjoint rows, so both commit, and the same unit gets double promised. That reframed the whole demo into a sharper lesson: consistency comes from modeling the contended resource as one authoritative, uniqueness protected row.

I also handled DSQL's short lived auth tokens, which are regenerated per connection, and spent real effort making the console self explanatory for viewers who do not work in blood banking.

Accomplishments that I'm proud of

I turned a distributed systems guarantee into something you can watch. Under a simulated surge, the legacy engine double promises a unit and the counter climbs, while Sanguine on Aurora DSQL holds at zero, every time. No invented numbers: every value comes from real transactions against a live DSQL cluster.

I also built a coherent product rather than a single trick. The flow runs end to end: discover supply across centers, prioritize by emergency tier, allocate with a real strong consistency transaction, see the whole network, and audit every decision.

What I learned

Pick the database for the guarantee you need. Strong consistency was not a nice to have here. It was the entire value proposition, and choosing Aurora DSQL because the problem demanded it made every later decision simpler.

Embrace the engine's model. DSQL's optimistic concurrency felt like a constraint at first, then became the thing that made the demo sharp.

Show the guarantee, do not assert it. The most convincing thing you can do with a correctness property is let people watch the wrong approach fail next to the right one.

A single uniqueness constraint earns more trust than any amount of application code.

What's next for Sanguine

Connect real blood banks and hospital systems across a region. The multi tenant model already supports many facilities on one network.

Delivery and SLA proof: a transit to delivered lifecycle, with billing only on verified delivery.

A replenishment step that fires outreach when a center's stock for a type drops below par.

Role based workspaces with SSO, and national shortage visibility so coordinators see where supply is low before it becomes a crisis.

Built With

• amazon-aurora-dsql
• amazon-bedrock
• amazon-web-services
• aws-iam
• framer-motion
• next.js
• node.js
• react
• tailwindcss
• typescript
• vercel
• zod