Playbook
Multi-Node Clusters Without the Single-Brain Myth (Multi Node Clusters Without Single Brain Myth)
Multi-Node Clusters Without the Single-Brain Myth — a production lesson from an ABC Logistics backend/data platform.
Logistics Polyglot Data Platform
Part 6 of 10
Cleansing ERP MySQL into PostGIS, MongoDB for telemetry, and Elasticsearch for search across a polyglot logistics data platform.
Multi-Node Clusters Without the Single-Brain Myth
Multiple nodes are not magic: replicas, shard allocation, and failover drills decide whether search/telemetry survive a host loss.
ES/Mongo nodes × replica × failover
Cluster diyagramı olmadan ‘HA’ iddiası boştur.
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
Multiple nodes are not magic: replicas, shard allocation, and failover drills decide whether search/telemetry survive a host loss.
ES/Mongo nodes × replica × failover
The split that works
Cluster diyagramı olmadan ‘HA’ iddiası boştur.
ES/Mongo nodes × replica × failover
↓
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?
Cluster diyagramı olmadan ‘HA’ iddiası boştur. Multiple nodes are not magic: replicas, shard allocation, and failover drills decide whether search/telemetry survive a host loss.
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
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.
Next in series
Elasticsearch for Ops Search Across Entities
Elasticsearch for Ops Search Across Entities — a production lesson from an ABC Logistics backend/data platform.
Same series
MongoDB for High-Frequency Telemetry
MongoDB for High-Frequency Telemetry — a production lesson from an ABC Logistics backend/data platform.