Playbook
Data Contracts for Geofence and Expeditions (Data Contracts For Geofence And Expeditions)
Data Contracts for Geofence and Expeditions — a production lesson from an ABC Logistics backend/data platform.
Logistics Polyglot Data Platform
Part 9 of 10
Cleansing ERP MySQL into PostGIS, MongoDB for telemetry, and Elasticsearch for search across a polyglot logistics data platform.
Data Contracts for Geofence and Expeditions
Contracts carry km_metric, centers, wait reasons, and expedition ids so the Wait Geofence UI and expedition map stay aligned.
km_metric, center, wait reason, expedition id
km_metric kontratı UI ile PostGIS’i birleştirir.
Concepts, defined where they first appear
📦 Operational Store
MySQL written by the ERP — right for daily ops, dirty for analytics.
📦 Analytics Store
Cleansed PostgreSQL/PostGIS for geo queries and reporting.
📦 Telemetry Store
Document store (MongoDB) for high-frequency location events.
📦 Search Index
Elasticsearch cluster for cross-entity ops search.
Blurring these layers produces the wrong truth in analytics and on the map UI.
Shape of the problem
Contracts carry km_metric, centers, wait reasons, and expedition ids so the Wait Geofence UI and expedition map stay aligned.
km_metric, center, wait reason, expedition id
The split that works
km_metric kontratı UI ile PostGIS’i birleştirir.
km_metric, center, wait reason, expedition id
↓
explicit contract → frontend
Frontend bridge
Ops maps, wait-geofence UI, and MFEs consume these read models — they never bind to raw ERP/MySQL.
The mappings that get confused most often
❌ ERP MySQL = analytics database
✓ ERP is a write store; analytics lives in PostGIS
❌ Let the map trust public/vendor routers blindly
✓ Production needs your API/OSRM edge
❌ Log ML outputs with PII
✓ Evaluation and serving obey privacy boundaries
A checklist for auditing your own system
- Which store is source of truth for this surface?
- Which API contract does the frontend call?
- What happens if one cluster node dies?
- How is lag shown to operators?
- Deny-list: any client domain/vendor leakage?
What to take away from this part
- Polyglot stores exist for different workloads; one-DB fantasies are fragile.
- Frontends consume clean read models, not the ERP.
- ML/OSRM outputs need an API contract before they hit the map.
A beautiful map drawn from a dirty source is still a lie.
FAQ
Frequently asked questions
What is Operational Store?
MySQL written by the ERP — right for daily ops, dirty for analytics.
What is Analytics Store?
Cleansed PostgreSQL/PostGIS for geo queries and reporting.
Is it true that "ERP MySQL = analytics database"?
ERP is a write store; analytics lives in PostGIS
What does this part lock in?
km_metric kontratı UI ile PostGIS’i birleştirir. Contracts carry km_metric, centers, wait reasons, and expedition ids so the Wait Geofence UI and expedition map stay aligned.
Engineering Principles Learned
- Separate the operational store from the analytics store.
- Telemetry, search, and relational GIS have different access patterns.
- Every read model is a frontend contract.
Continue reading
Continue reading
Next in series
Observing Lag Across Polyglot Stores
Observing Lag Across Polyglot Stores — a production lesson from an ABC Logistics backend/data platform.
Next in series
Serving Clean Reads to Ops Frontends
Serving Clean Reads to Ops Frontends — a production lesson from an ABC Logistics backend/data platform.
Same series
Anti-Corruption Between ERP (Enterprise Resource Planning) and Analytics
Anti-Corruption Between ERP and Analytics — a production lesson from an ABC Logistics backend/data platform.