HELLMANN WAREHOUSE WORKFLOW PLATFORM.
An event-sourced workflow platform that tracks every purchase order through 11 stages across 9 operational teams of a third-party logistics warehouse, replacing spreadsheet coordination and verbal hand-offs with live tablet, desktop and overhead-screen workflows
THE
ARCHITECTURE
Before the platform, nobody could see where a purchase order sat on the floor: picks were confirmed verbally, hand-offs happened between shifts by word of mouth and routing was worked out by hand from a shared spreadsheet. The platform gives each of the 9 teams the same lifecycle — Queue → Accepted → Ongoing → Finished — on tablet operator screens, desktop control panels, overhead TV boards and reports, all updated live over WebSockets.
The backend is split into three services: a FastAPI api that runs the workflow engine and serves REST and WebSocket traffic, a worker that consumes RabbitMQ for notifications and background jobs, and an integration service that is the only component allowed to reach the internet. State is event-sourced: nothing is updated in place, every action is appended to an events table in PostgreSQL and current state is rebuilt by replaying it. The 11 stages, their routing rules, preconditions and escalations live in a versioned YAML workflow definition, so changing the process is a config change, not a code change.
PHASED
ROLLOUT
Running live with early teams while the legacy spreadsheet process continues in parallel.
- Complete
Requirements & prototype
Operational pain points — no live PO visibility, verbal hand-offs, manual routing — turned into system requirements and a screen-by-screen prototype.
- Complete
Core engine & 9 team workflows
Event store, YAML workflow engine, per-team screens, dashboards and reports.
- Complete
Test deployment with client IT
Cloud Run test environment validated against real operational data.
- Now
Phase 1 — live alongside Excel
Early teams run their work in the platform while the legacy spreadsheet process continues in parallel.
- Planned
UAT & full cutover
Acceptance testing, then retiring the spreadsheet process team by team.
- Planned
Phase 2 — WMS integration
Direct integration with the warehouse management system and further client workflows on the same engine.
Partial releases. The unit that moves through the floor is a release of a purchase order, not the order itself, and the PO status is a rollup over its releases. One order can be in Pick, Split and Loading at the same time — the way the warehouse really works.
Undo by appending, never deleting. Reversing a bad planning upload writes compensating events instead of UPDATE or DELETE, and a test asserts it. If the floor has already started the work, undo raises a reconciliation task instead of silently rewriting history.
Idempotent spreadsheet ingest. During the parallel run, planning data still arrives as spreadsheets. Uploads are keyed by file hash, so a re-upload never creates duplicate work.
Ping, then re-fetch. The server pushes a lightweight "changed" signal over WebSockets and screens re-fetch with debouncing, rather than streaming full payloads — keeping dozens of tablets and TV boards consistent with one source of truth. Workflow preconditions run through a whitelisted expression evaluator, never eval.
Key
Technical Decisions
My
Contributions
01. Requirements gathering
Took part in requirements and planning meetings, translating operational pain points into system requirements.
02. Tablet operator screens
React and TypeScript screens taking work from queue to finished, with hold and rollback.
03. Bulk actions & reports
Bulk actions with live progress, and a reports page with CSV and Excel export.
04. API & queries
FastAPI endpoints and PostgreSQL queries behind dashboards and reports, covered by automated backend tests.
05. Carton weight verification
A FastAPI webhook service validating scale scans against per-carton baselines within a configurable tolerance — atomic, out-of-order-safe writes feeding live bay screens, quarantine for unregistered scales, config changes without redeploys, an offline test suite and a CLI simulator, on Cloud Run with structured logging.
06. Live team-card counts
Live per-team counts on the operations console, refreshed by WebSocket pings with no polling, a per-user cache and no stale numbers — handling StrictMode double-mounts, hidden tabs and request coalescing.
TECHNICAL
CHALLENGES
01. Running Beside the Old Process
The platform goes live team by team while spreadsheets keep running. Idempotent uploads, reversible undo and reconciliation tasks keep both worlds consistent, so a team can adopt it without the rest of the floor changing how it works.
02. Live Screens Under Load
A live dashboard exhausted the database connection pool during testing. A lighter endpoint, a short shared replay cache, a fallback poll and a warm minimum instance took median response from 4.4s to 0.09s.
03. Out-of-Order Scale Data
Floor scales post weights over webhooks with no ordering guarantee. Writes are atomic and order-safe, and scans from unknown scales are quarantined rather than dropped — no data loss, no wrong reading on a bay screen.
IMPACT & METRICS