FieldForge

Dispatch uses Redis geospatial search to find technicians near the job location. Candidates are ranked with a deterministic score based on distance, rating, completed jobs, and certification matches.

Technicians can submit bids only for published work orders. Duplicate pending bids are blocked. Accepting a bid locks both the bid and work order before selecting the winner, rejecting competing bids, and assigning the technician.

That keeps the marketplace state clear: one accepted bid, one assigned technician, and one work order status.

Work orders move through a controlled lifecycle: draft, published, assigned, en route, on site, completed, approved, paid, cancelled, or disputed. Each transition checks the current state, caller role, and ownership before updating the order.

Database transactions and row locks protect important changes. Publishing a work order, accepting a bid, assigning a technician, and marking a job paid all update the domain record, status history, and events together.

The technician app supports travel start, check-in within a 200-meter geofence, before and after photos, serial numbers, signatures, and job completion. Offline actions are queued locally with idempotency keys and replayed in order when the device reconnects.

Billing is modeled around escrow-style holds. A buyer can lock funds for a work order, and funds can be released only after the work is approved by an authorized user.

The release path uses idempotency records, row locking, and a single escrow account per work order to prevent duplicate payouts. It records payout ledger entries, generates invoice data, and can refund unused escrow balance when the final payout is lower than the held amount.

Payment provider behavior sits behind an interface, with a deterministic ledger provider for local development and tests. That keeps billing rules testable without depending on a live provider.

Work-order and billing services write domain events into an outbox inside the same transaction as the business change. A relay publishes those stored events to RabbitMQ after commit, so a broker failure does not erase the business event.

The outbox relay claims small batches with row locking, uses expiring leases and claim tokens for recovery, keeps events ordered per aggregate, applies publish timeouts, retries temporary failures with backoff, and marks malformed payloads as dead.

Consumers use Redis-backed event deduplication, keep correlation IDs, retry failed handlers a limited number of times, and route exhausted attempts to dead-letter queues.