Playbook
Anti-Corruption Between ERP (Enterprise Resource Planning) and Analytics (Anti Corruption Between Erp And Analytics)
Anti-Corruption Between ERP and Analytics — a production lesson from an ABC Logistics backend/data platform.
Logistics Polyglot Data Platform
Part 7 of 10
Cleansing ERP MySQL into PostGIS, MongoDB for telemetry, and Elasticsearch for search across a polyglot logistics data platform.
Anti-Corruption Between ERP (Enterprise Resource Planning) and Analytics
Never mirror ERP table names into analytics or frontend DTOs; translate at the boundary.
ERP schema ⇢ translator ⇢ analytics model
Anti-corruption, hukuki ve teknik sızıntıyı keser.
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
Never mirror ERP table names into analytics or frontend DTOs; translate at the boundary.
ERP schema ⇢ translator ⇢ analytics model
The split that works
Anti-corruption, hukuki ve teknik sızıntıyı keser.
ERP schema ⇢ translator ⇢ analytics model
↓
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?
Anti-corruption, hukuki ve teknik sızıntıyı keser. Never mirror ERP table names into analytics or frontend DTOs; translate at the boundary.
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
Serving Clean Reads to Ops Frontends
Serving Clean Reads to Ops Frontends — a production lesson from an ABC Logistics backend/data platform.
Next in series
Multi-Node Clusters Without the Single-Brain Myth
Multi-Node Clusters Without the Single-Brain Myth — a production lesson from an ABC Logistics backend/data platform.
Same series
Data Contracts for Geofence and Expeditions
Data Contracts for Geofence and Expeditions — a production lesson from an ABC Logistics backend/data platform.