Reliability
Tracking doesn't stop
because software did
A tracking desk is a live operation. If the board is down, loads are still moving and nobody knows where they are. Here is what the platform does to make sure that stays hypothetical.
3
availability zones, with automatic database failover
15s
fastest refresh on the live tracking board
30
days of point-in-time database recovery
Staying up
No single machine, and no single availability zone, can take the platform down.
The database fails over on its own
Aurora PostgreSQL runs a writer and a reader in separate availability zones. If the writer is lost, the reader is promoted automatically — there is no call to make and no runbook to find.
Always more than one of everything
The application never runs fewer than two tasks, spread across three availability zones, and scales out to five under load. Losing a task, or a zone, costs capacity rather than service.
A bad deploy rolls itself back
Deployments watch their own health. A release that fails its checks is reverted to the previous version automatically, before it can take traffic.
Slow work cannot block a page
Anything that touches a third party — a TMS write, an SMS, a voice call, a report — is handed to one of nine dedicated background queues. A carrier's TMS having a bad afternoon slows that queue and nothing else.
Staying fast
The board is quick because the work happened before you asked, not because the query is clever.
Dashboards read pre-computed data
Tracking boards are served from materialized views that refresh in the background as often as every fifteen seconds. Opening a board runs no expensive query — the answer is already sitting there.
Reads stay off the write path
Reporting and dashboard queries are served by a dedicated read replica, so a heavy export cannot slow down the load that is being updated at the same moment.
Heavy computation lives elsewhere
Workflow calculations, load rendering, mapping and metrics each run as their own service. One of them being busy does not make the rest of the application slower.
Row-level updates, not page reloads
When a load changes, that row changes. Trackers work a board that updates underneath them instead of re-fetching a screen they are in the middle of reading.
Noticing before you do
The failure mode we design against hardest is the one that looks fine.
Every integration is checked on a timer
Each TMS connection is health-checked every fifteen minutes, and the scheduler itself reports a heartbeat every sixty seconds. A sync that stops is an alert, not a gap somebody spots next week.
A failed write is loud
If your TMS refuses an update or stops responding, the load says so on the board and the team is told. A tracking platform that silently drops an update is worse than one that is visibly down.
The database is watched, not assumed
Memory headroom, CPU credit balance, swap and replica lag each carry their own alarm with thresholds set from real incidents rather than from defaults.
Growing without a migration
The thing that usually breaks when a brokerage doubles is not the software, it is the assumption underneath it. Three we deliberately didn't make.
Volume is a number, not a tier
Load volume drives how many workers pick up the queue, not which version of the product you are on. Doubling your freight does not move you onto a different platform or a different codebase.
Adding a TMS doesn't disturb the first one
Each integration is its own service with its own credentials and its own deployment. Bringing a second brand or a second TMS online has no bearing on the one already running.
More users is not more load
Boards are served from data computed on a schedule, so the cost of a page view barely moves with the number of people looking at it. Twenty trackers and two hundred read the same pre-built answer.
Ask us the hard version of these questions
We would rather answer them on a call than have you find out later that the answer was marketing.