Fleet dispatch app scaling and launch checklist

• Pagination: Shipment, event and audit lists use keyset pagination on (created_at, id); maps load only bounding-box visible vehicles and stops, capped at 500 markers with clustering on the client.
• Caching: Last vehicle positions are an upserted column read by the live board; geocoding results and routing distances are cached by normalised address or coordinate pair for 30 days to stay inside provider budgets.
• Idempotency: Stop events carry a client event id and shipments an Idempotency-Key or customer reference unique per account so offline replays and API retries are exactly-once in effect.
• Rate limits: Ping endpoint accepts at most one batch per 5 seconds per device with a payload cap; public tracking pages are rate limited per IP and token; customer API keys have per-minute quotas.
• Data growth: location_pings are partitioned by day and pruned after the retention window; stop_events and audit_log are partitioned by month and archived read-only.
• Realtime: Live board and tracking pages use SSE fed by Postgres NOTIFY per depot or token with a 15-second poll fallback; no dedicated websocket tier in phase 1.
• Storage: Proof photos and signatures use presigned PUT, are resized on a worker, stored under non-guessable keys and served by signed URLs; retention follows contract terms.

• Metric pings per second and ping reject total: by operator; rejects by reason.
• Metric on time delivery rate: by customer, depot and day.
• Metric webhook delivery failures: attempts, dead letters and age.
• Log dispatch audit log: request id, actor, route and stop ids, outcome; recipient details excluded.
• Trace stop event trace: event insert, status update, notification, webhook.
• Slo event durability: 100% of accepted driver events are stored exactly once; replay mismatches are incidents.
• Slo tracking freshness: 95% of active vehicles have a position under 60 seconds old.
• Alert vehicle silent: vehicle on active route without a ping for 5 minutes alerts the dispatcher.

• deliver_webhooks: runs queue (jobs) and cron every minute for retries. Guard: SKIP LOCKED claim, exponential backoff, attempt cap 8, dead letter with alert.
• recompute_etas: runs cron every 2 minutes for active routes. Guard: bounded to routes started today, uses last position and remaining stops, one routing-API call per route per interval within the budget.
• prune_location_pings: runs cron daily. Guard: drops expired daily partitions after downsampling; never touches active partitions.
• check_vehicle_compliance: runs cron daily. Guard: creates tasks 30/14/7 days before document expiry and maintenance due; idempotent per item and threshold.
• notify_milestones: runs queue (jobs) on stop event. Guard: one message per (stop, milestone, channel), respects opt-in and daily cap.
• verify_audit_chain: runs cron nightly. Guard: incremental hash chain recompute, break is a sev-1.

• Read replicas: Delivery analytics and utilisation reports run on a read replica when primary CPU > 60% sustained; dispatch and driver endpoints use the primary.

Forge64 matches your description to one of 25 reference architectures, writes the plan and data model into the project, generates the app, and runs a quality gate over the code before you see it. Each app gets its own Postgres database and sign-in with no per-user fee. Hosting on Forge Cloud and Forge Payments are rolling out.

Every metered resource on Forge64 has a hard cap, so a traffic spike stops at your limit instead of becoming a surprise bill. This is a reference design for the category, not a promise that every item is generated today. Built-ins such as background jobs, file uploads and search are rolling out; email sent from your app is coming soon, so anything here that needs it is something you add yourself for now.

When should I worry about scale for a fleet dispatch app?

Not before a measured trigger fires. For example, for "Vehicle routing solver (VRP) as a batch service": more than 30 stops per driver-day or customer asks for auto-planning.

What performance targets should a fleet dispatch app aim for?

Driver event submit: p95 < 150 ms, one insert. Dispatch board load (1,000 stops, 80 vehicles): p95 < 600 ms with clustered markers. Ping batch of 60 points: p95 < 200 ms.

Does Forge64 cap my usage costs?

Yes. Every metered resource has a hard cap, and paid plans add an overage spend cap that you set.

• How to build a fleet dispatch app
• Fleet dispatch app architecture
• Example prompt for a fleet dispatch app
• Fleet dispatch app security checklist
• Often combined: inventory system
• Often combined: booking system
• All app types