Meridian Flow: Engineering a Multi-Tenant Dispatch Platform for Freight Operations.
How Grotics partnered with a freight operations team to design, build, and ship a multi-tenant dispatch platform — replacing manual spreadsheets with one auditable system of record.
Event-Driven SaaS
Modular monolith with strict data isolation
Greenfield Build
Delivered alongside the client team
Core Engine & Payouts
Postgres RLS, Fastify, Stripe Connect
Client AWS & repositories
No lock-in; in-house handover
Client-Owned Stack
Runs in the client's own AWS account
One state of truth per load
Each load moves through a single, unambiguous lifecycle. Carrier updates arrive as events, are validated once, and are appended to an immutable history — so two dispatchers can never book the same load twice.
Tenant context comes from signed JWT claims
Loads are claimed under advisory locks before assignment
Status changes are appended once and never overwritten
Carrier payouts settle from the double-entry ledger
Dispatch bottlenecks threatening operational scale.
Freight brokerages and multi-carrier fleets live on fast, volatile transactions. Before Meridian Flow, dispatch teams relied on a patchwork of spreadsheets, a legacy transport management system, and manual PDF reconciliation runs.
Settlement runs across spreadsheets and PDFs
Line-item checks across carrier fuel surcharges and accessorial fees were slow and easy to get wrong.
The same load, booked twice
When rates moved fast, dispatchers working in parallel could assign the same load to competing carriers without noticing.
Core Operational Bottleneck
Uncoordinated state meant untracked detention fees, duplicate booking penalties, and numbers nobody fully trusted. The team needed one system where a load could never sit in an ambiguous state.
Senior-Led Pod. Zero Middleware Layers.
No committees, no hand-off to a junior bench. Meridian Flow worked directly with a three-person senior team inside their own Slack and GitHub organization.
Systems Architect
Database Schema, RLS & Cloud Infra
Authored the PostgreSQL declarative permission model, Temporal state machine graphs, and automated AWS CDK multi-environment infrastructure.
Senior Backend Engineer
Fastify, Webhooks & Stripe Connect
Engineered the dispatch routing gateway, out-of-order webhook reconciliation queues, and automated multi-party escrow clearing logic.
Senior Frontend Engineer
React, Real-Time Streams & UX
Delivered keyboard-driven, high-density dispatcher views, live GPS telemetry maps, and responsive optimistic state updates.
Technical Blueprint: The Modular Dispatch Engine
Designed for consistency without distributed-system overhead: a modular monolith deployed on AWS ECS, with isolation enforced inside the database.
1. Ingress & Auth
Fastify Node.js gateway with Zod payload validation. JWT identity paired with signed tenant claims.
2. Postgres RLS Engine
PostgreSQL with database-level Row-Level Security. Every single query enforces current_setting('app.tenant_id').
3. Temporal.io Workflows
Distributed durable execution. Manages multi-day driver trips, automatic timeout escalations, and out-of-order telematics events.
4. Double-Entry Ledger
Immutable debit/credit journal table, settled through Stripe Connect so carrier payouts follow the ledger.
Why Modular Monolith Over Microservices?
Splitting this into microservices would have meant distributed transactions across the money paths and a lot of operational overhead for a small team. Keeping clean module boundaries inside one deployable unit keeps dispatch and ledger writes transactional and the codebase easy to navigate.
Engineering Trade-Offs & Defensive Design
What separates a demo from a system you can operate: how edge cases and contention are handled at the database and network layers.
Multi-Carrier Webhook Idempotency
Carriers send updates via webhooks that arrive out-of-order, duplicated, or delayed. Naive updates would regress a load from "Delivered" back to "In-Transit".
Implemented a Redis-backed distributed lock with a monotonic event counter. Webhooks are staged into an append-only event stream; out-of-order payloads are rejected or reconciled against the carrier's state vector.
Strict Multi-Tenant Database Isolation
Freight brokers handle confidential spot margins. Relying only on application-level where("tenant_id", id) filters leaves room for human error.
Configured native PostgreSQL Row-Level Security policies tied directly to connection pool session variables. Even if an engineer writes an unbounded query, the database engine returns zero rows from other tenants.
High-Speed Driver Allocation Race Conditions
During morning peaks, many dispatchers bid on the same high-value loads at once, which produced phantom assignments and double-booked carriers.
Replaced standard database optimistic locking with Postgres advisory transaction locks paired with WebSocket presence markers. Dispatchers see instant visual reserve locks before submission.
What the first release shipped with.
The first release went out with the tooling and documentation the in-house team needed to run the platform themselves.
One deployable, clean boundaries
Dispatch and ledger writes stay transactional in one system.
Isolation enforced in the database
Every query runs under a tenant-scoped session.
Durable trips and retries
Long-running trips survive restarts, delays, and out-of-order updates.
Payouts from the ledger
Settlement entries post before money moves.
The engineers who designed the system are the ones who built it, documented it, and stayed in the client's Slack until handover was done.
Building a high-concurrency SaaS platform?
Let's talk through your data model, API requirements, and infrastructure trade-offs before the first schema is written.