The Problem
An automotive service network operating more than 12,000 service centers across multiple markets was running diagnostics on a per-center basis. Each location used locally installed tooling, its own fault-code library version, and its own process for interpreting DTC (Diagnostic Trouble Code) data from vehicles. The result was predictable: inconsistent diagnoses, no centralized visibility into fleet health, and no mechanism to push updated repair guidance when a common fault pattern was identified.
The cost was invisible until you added it up. Technicians spent significant time looking up fault codes in static PDF manuals or outdated local databases. Misdiagnosis rates drove unnecessary parts replacements. When a software-related fault affected a large vehicle cohort, the service network had no way to notify centers and push updated procedures before customers arrived with the problem.
The Constraints
Multi-OEM, multi-market fault catalogue. The service network covered vehicles from multiple manufacturers across different model years and regional variants. The platform needed to normalize fault codes across OEM-specific DTC namespaces into a consistent internal representation — without losing the OEM-specific repair context that technicians needed.
Real-time query performance at scale. A technician connecting a diagnostic tool to a vehicle expects results in under two seconds. The platform needed to handle concurrent queries from thousands of centers without performance degradation — including during regional peak hours when a product recall drives simultaneous demand.
Fault pattern detection and proactive guidance. The network wanted to move from reactive diagnostics to proactive fleet health management: identify fault patterns as they emerged, push updated repair guidance centrally, and give service managers visibility into recurring issues before they became warranty claims.
Offline resilience. Service centers in some markets had unreliable internet connectivity. The platform architecture needed graceful degradation — local fault-code cache for common DTCs when the central system was unreachable, syncing when connectivity restored.
Our Approach
The platform is built around a central fault ingestion and normalization service that accepts DTC data from diagnostic tools in their native OEM formats and maps them into a normalized fault catalogue. The normalization layer handles OEM-specific encoding differences, model-year variations, and regional DTC namespace conflicts — producing a consistent internal representation that the rest of the platform queries.
The fault catalogue database is PostgreSQL with a materialized-view layer optimized for the most common technician query patterns: by DTC code, by vehicle VIN prefix (narrowing to a model variant), and by symptom description. Sub-2-second query performance at 12,000 concurrent users required careful index design and query plan optimization — not horizontal scale.
The workshop interface surfaces the fault code, the normalized repair procedure, associated TSBs (Technical Service Bulletins), parts lists, and related fault patterns from the same vehicle cohort. Technicians see the full repair context in a single view rather than switching between systems.
The fleet health dashboard aggregates fault frequencies across the network in near-real-time, surfacing emerging fault patterns before they reach support thresholds. Network managers can push updated repair guidance to all centers simultaneously when a new fault pattern is identified or a recall instruction needs distributing.
Local fault-code caching at the workshop level handles offline resilience — a SQLite cache of the most recent fault catalogue query results syncs with the central system and degrades gracefully when connectivity is lost.
The Outcome
- 12,000+ service centers migrated from fragmented local tooling to a single centralized platform
- Sub-2-second fault query response across the full multi-OEM vehicle catalogue under production load
- Manual fault-code lookup eliminated — technicians see normalized repair context, TSBs, and related fault patterns inline
- Fleet-wide diagnostic visibility — the first time the network had a real-time view of fault frequency and cohort health across all locations
- Centralized guidance push — updated repair procedures reach all 12,000 centers in under 5 minutes
Team
Engagement: 6 months, 4 engineers (1 backend, 1 data, 1 frontend, 1 platform).
Stack: Python, Node.js, PostgreSQL, Redis, SQLite (local cache), React, AWS (RDS, Lambda, CloudFront), REST APIs