Event-driven warehouse management at multi-site scale

The problem

Cannabis logistics in the US is a heavily regulated industry, which changes what a warehouse management system has to be. It is not enough for inventory to be correct — you have to be able to prove it was correct, and prove who changed it, across multiple physical sites operated by different companies on the same platform.

That combination — multi-site, multi-tenant, and audit-grade — is what pushed the architecture away from a single application and toward a set of services with a durable event log between them.

Architecture

We built a fleet of independently deployable Node.js and TypeScript services running on AWS EKS and ECS on Fargate behind load balancers, communicating over a NATS Streaming event bus.

The reason for an event bus rather than direct service-to-service calls was specific, not fashionable. In a warehouse, a single physical action — a pallet moves, a scan fires — has consequences in inventory, in order fulfilment, and in the audit record simultaneously. Modelling that as one event that several services independently react to means the audit trail is a first-class consumer rather than a logging afterthought, and a slow consumer never blocks the floor.

Fargate was the deliberate call: a four-person team should be spending its time on domain logic, not on keeping a node group healthy.

The data layer

Inventory search across three fulfilment centres was the query-heavy surface, and it was running on Amazon Redshift. I owned the migration to ClickHouse, which cut infrastructure cost while preserving the fast columnar behaviour the search UI depended on.

The migration mattered more than the line item suggests: warehouse search is the screen operators live in all day, so a change there is only acceptable if latency holds. Preserving query performance was the constraint; cost reduction was the goal.

The operator-facing surface

Alongside the services, we delivered a multi-warehouse B2B SaaS operations suite:

• Zone management — modelling the physical layout of each facility so inventory has a real location, not just a count.
• Per-resource RBAC — because "who can see this" in a multi-tenant regulated platform is per-resource, not per-role-globally.
• Compliance-grade cycle-count auditing — reconciliation that produces a defensible record, which is the whole point in this industry.
• RFID hardware integration — bridging physical scanning hardware into the event stream.

Release engineering

A microservices fleet is only an advantage if you can actually release the services independently. I built the CI/CD pipelines that gate every service on lint, test and deploy stages, which removed the manual release steps that otherwise scale linearly with the number of services — the failure mode that quietly turns a microservices architecture back into a distributed monolith.

Leading the team

Four engineers, one shared event contract. The thing I'd emphasise from that year is that in an event-driven system the schema of the events is the team's API to each other. Most of the coordination cost went into keeping those contracts explicit and stable, and most of the avoidable bugs traced back to moments where they weren't.

Verification

Leafgistics is a named client in BitsPro's own public portfolio, so this work is externally checkable — the microservices packages published under the client's npm organisation carry a BitsPro maintainer address. I've deliberately left out the client's own business and funding figures here; those were not mine to influence and they aren't evidence of anything I did.