MMS Technical Architecture: How We Designed a Unified Maintenance System

The Problem We Were Solving

Most factories run maintenance operations across disconnected tools: paper logs, WhatsApp groups, phone-based ticketing, and siloed spreadsheets. None of these communicate with each other. None of them give you a real-time answer to the most basic question: which machines are down right now, and why?

Operational excellence starts when maintenance data moves from disconnected messages into one real-time operational timeline.

The specific challenges we designed against:

• Disconnected tools — Paper for recording, WhatsApp for communication, phone calls for breakdown tickets with no logging trail.
• No centralized visibility — No way to know how many assets were idle, their exact floor location, or which assets had recurring problems.
• Mechanic-supervisor friction — Breakdowns triggered clashes over responsibility, with no structured Time & Action tracking.

Application Landscape Integrations

MMS doesn't operate in isolation. It sits at the intersection of four existing systems:

System	Role in MMS
WMS	Source of machine data and spare parts inventory
WFX ERP	Source of machine cost details and CRM context
IHRMS	Provides shift roster and line-responsible persons for approval/notification workflows
MES	Provides quick changeovers and direct operation locations including sewing line data

This integration design meant MMS didn't need to own all the data — it needed to consume and coordinate across existing systems, not duplicate them.

Architecture Decisions

Core Services

Domain

Asset Service

Owns machine master data, warranty/AMC details, and floor-level location mapping.

Domain

Downtime Workflow

Captures supervisor breakdown events, routes escalation, and enforces closure governance.

Integration

Spare Parts Service

Connects with WMS and maps parts issuance directly to work-order lifecycle.

Intelligence

KPI and Analytics

Computes MTTR, MTBF, response SLAs, and utilization from one event stream.

The MMS is structured around independently deployable services:

• Asset Service — Master data for all machines: location, warranty, AMC, QR coding, department ownership.
• Maintenance Scheduler — Preventive and corrective task planning, calendar-based trigger engine.
• Downtime Workflow Engine — Supervisor-initiated breakdown logging, escalation rules, and closure governance.
• Spare Parts Inventory — Linked to WMS, tracks issuances against work orders and triggers reorder requests.
• Notification & Approval Router — Uses IHRMS shift data to route alerts to the correct person on shift.
• Reporting & KPI Engine — Aggregates OEE components, MTTR, MTBF, and response times into role-based dashboards.

Technology Stack

Layer	Choice	Rationale
API / Backend	NodeJS	Async I/O suits high-frequency event processing (breakdowns, alerts, status updates)
Database	MySQL	Relational structure needed for asset + work order + spare part linkages
Frontend	React	Component-driven UI supports role-specific dashboards (supervisor, mechanic, store keeper)
Caching / Locking	Redis	Real-time mechanic availability, Redlock for concurrent work order assignments
Container Orchestration	Kubernetes	Microservice deployment, scaling individual services under load spikes

Why Redis Mattered Here

Mechanic availability is a real-time resource allocation problem. When a breakdown is logged, the system needs to:

1. Know which mechanics are currently free vs. assigned.
2. Lock the assignment to prevent double-allocation.
3. Release the lock if the assignment is rejected or times out.

Redis served both as the availability cache and the Redlock distributed lock implementation across service instances. Without it, concurrent breakdown events would cause race conditions in mechanic dispatch.

Weighted Resource Pooling for Mechanic Assignment

We recently implemented a section-scoped resource pooling algorithm for breakdown assignment.

• Mechanics log in to a specific section of the unit.
• Breakdown tickets are pooled and consumed only within that section.
• Assignment priority is weight-driven: mechanics with fewer completed tickets are selected first.
• This avoids assignment concentration and improves fairness under sustained load.

The assignment engine follows a Node.js event-loop style flow:

1. Consume breakdown-raised events from the section queue.
2. Fetch available mechanics and compute current weights.
3. Select the minimum-weight mechanic.
4. Acquire assignment lock and publish mechanic-assigned.
5. On timeout/reject, release lock and re-queue.

This model improved balancing and kept assignment latency stable even during multi-ticket bursts.

Role-Based System Design

One of the architecture principles we enforced was: each role sees only what it acts on.

Role	Primary Concern
Maintenance Engineer	Execute preventive and corrective tasks, update breakdown status
Supervisor	Log breakdowns, approve downtime corrections with system timestamps
Store Keeper	Manage spare parts, issue to work orders, initiate reorders
Mechanic Head	Manage and reallocate mechanics to reduce resolution time
Executive / IE Engineer	Layout planning, machine allocation, quick changeover scheduling
Plant Head	Full visibility — all machines, all maintenance, all performance metrics

This wasn't just a UI concern. Role-based data scoping was enforced at the API layer so that a supervisor's query never returned stale data from a different shift or floor section.

Business Challenges the Architecture Addresses

Unplanned Downtime

Predictive and preventive scheduling reduces unexpected failures. The scheduler triggers work orders based on machine run hours, service intervals, and historical breakdown patterns.

Inventory Stockout / Overstock

Rather than blanket safety stock, spare parts availability is tracked per machine type. Reorder triggers are based on actual issuance velocity, not static min/max thresholds.

Data Silos

All maintenance events — service, downtime, spare part consumption, mechanic utilization — land in one system. Reports and dashboards are computed from one source of truth, not assembled from multiple exports.

Reactive Maintenance Culture

The transition from reactive to proactive required more than tooling. The architecture enabled: automatic PM reminder notifications to supervisors, SLA tracking per breakdown ticket, and escalation routing when SLAs were breached.

Benefits Realized

Uptime Direction

Higher Asset AvailabilityPreventive and predictive workflows reduced unplanned stoppages.

Cost Direction

Lower Emergency SpendSpare inventory became demand-aware instead of assumption-based.

Decision Speed

Near Real-TimeLeadership moved from delayed Excel exports to live dashboards.

• Increased Uptime — Proactive scheduling reduced unplanned breakdowns.
• Cost Reduction — Optimized spare parts inventory reduced carrying costs and emergency procurement.
• Data-Driven Decisions — Real-time dashboards replaced end-of-day Excel consolidations.
• Enhanced Compliance — Automated calibration and maintenance tracking against regulatory schedules.
• Streamlined Workflows — Eliminated context switching between paper, WhatsApp, and verbal escalations.
• Full Transparency — Asset health, vendor performance, and mechanic utilization visible in one interface.

Deployment Strategy

We recommended a phased rollout to minimize disruption:

Change management was treated as a first-class workstream — not an afterthought. User adoption training was scheduled by role, and the mobile interface was designed for mechanics who had never used a formal CMMS.

Key Takeaway

The MMS architecture succeeded because it was designed around operational reality first — disconnected tools, shift-based responsibility, and breakdown urgency — and then mapped to the technical stack, not the other way around. NodeJS, Redis, and Kubernetes weren't chosen to be modern; they were chosen because the problem demanded async event handling, distributed locking, and independent service scaling.