HattaDev
Menu
Enterprise Software

Smart Logistics Management System — Real-Time Fleet & Shipment Platform

ClientPT Pos Indonesia (Persero)
Year2025
Stack10 technologies
Scroll
Results & Impact

Key Performance Metrics

23

Improvement

15,000+

Scale

Business Challenge

The logistics provider operated across Sumatra, Java, Kalimantan, and Sulawesi with complex multi-modal routes involving trucks, ferries, and last-mile motorcycle delivery. Shipment tracking was reactive — customers called to ask where their shipment was, and dispatchers called drivers to find out. Fleet utilization averaged only 62% due to poor route planning and empty return trips. Driver management was fragmented across WhatsApp groups with no systematic performance tracking. Warehouse operations used paper-based checklists with no real-time inventory visibility.

## Solution Architecture

Solution Architecture

We built a distributed logistics system with microservices for Shipment Management, Fleet Management, Warehouse Operations, Route Optimization, and Analytics. The core innovation is a real-time tracking engine using GPS data streamed from driver mobile devices via WebSocket to a Go backend, processed through Redis Streams for real-time event processing, and persisted to PostgreSQL. Shipment status changes are published as events to RabbitMQ, triggering notifications to customers, updating warehouse allocation, and feeding the analytics pipeline.

### Real-Time Architecture

Driver mobile app (React Native) streams GPS coordinates every 5 seconds to the tracking service (Go). The service validates coordinates against planned routes, calculates ETA using historical traffic data and current conditions, detects route deviations triggering alerts to dispatchers, and publishes shipment events (departed, arrived, delayed) to RabbitMQ. The event stream feeds multiple consumers: notification service (push notification to customers), analytics service (shipment performance metrics), billing service (automated billing events).

### Route Optimization Engine

A custom route optimization service built in Go uses a genetic algorithm to optimize delivery routes considering multiple constraints: vehicle capacity, driver hours, delivery time windows, traffic patterns, road conditions, and ferry schedules for inter-island routes. The optimizer processes 15,000+ shipments daily in under 2 minutes, achieving 23% improvement in fleet utilization.

## Key Features

Key Features

Shipment management with real-time GPS tracking, status updates, and proof of delivery with photo capture and digital signature. Fleet management with vehicle tracking, maintenance scheduling, fuel consumption monitoring, and driver performance analytics. Driver mobile app for shipment assignment, route navigation, delivery confirmation, and communication with dispatchers. Warehouse management with barcode-based receiving, put-away, picking, packing, and shipping with real-time inventory synchronization. Route optimization with AI-powered multi-stop route planning. Analytics dashboard with fleet utilization, on-time delivery rate, cost per shipment, and warehouse throughput metrics.

## Technology Stack

Technology Stack

Go backend for performance-critical services (tracking, route optimization) utilizing goroutines for concurrent GPS stream processing. Next.js with React for the web dashboard and customer portal. PostgreSQL with PostGIS extension for geospatial queries — proximity searches, route containment, coverage area analysis. Redis Streams for real-time event processing with consumer groups for load balancing. RabbitMQ for asynchronous messaging between microservices. Docker containers orchestrated on Kubernetes with cluster autoscaling. AWS infrastructure with EKS, RDS, ElastiCache, and CloudFront CDN.

## Results

Results

Real-time shipment visibility reduced customer inquiry calls by 85%. Fleet utilization improved from 62% to 85% saving approximately Rp 12 billion annually in operational costs. On-time delivery rate increased from 71% to 94%. Driver productivity improved 40% through optimized routing and reduced idle time. Warehouse throughput increased 55% through barcode automation and real-time inventory management. Customer NPS improved from 28 to 72.

## Lessons Learned

Lessons Learned

Real-time GPS tracking at scale (1,500 devices × 5-second intervals) requires careful message batching and compression — raw GPS data would overwhelm the backend. The route optimization service must be designed as an eventually-consistent worker — optimizing 15,000 shipments should not block the ability to create new shipments. Mobile-first design for the driver app was non-negotiable: 80% of driver interactions happen on 4G connections in areas with intermittent coverage, requiring an offline-first architecture with local SQLite and background sync.

Technology Stack

Technologies Used

GoNext.jsTypeScriptPostgreSQLPostGISRedisRabbitMQDockerKubernetesAWS
More Work

Related Projects

Enterprise Software

Manufacturing ERP Platform — Enterprise Production Management

A cloud-native Enterprise Resource Planning system built for a multi-factory manufacturer producing 50,000+ SKUs across 8 production lines. The legacy system — a combination of Excel spreadsheets, disconnected Tally installations, and paper-based quality control — was causing production delays, inventory discrepancies, and financial reporting that lagged 2-3 weeks behind actual operations. ## Business Challenge The manufacturer operated 3 factories across Java with 2,000+ employees and a complex supply chain involving 300+ raw material suppliers. Each factory ran its own spreadsheet-based production schedule with no real-time visibility into material availability, work-in-progress status, or quality metrics. Procurement was reactive rather than planned, resulting in both stockouts stopping production lines and overstock tying up working capital. Financial consolidation required 5 accountants spending 10 days per month reconciling data from three separate systems. ## Solution Architecture We designed a modular ERP platform with bounded contexts for Production Planning, Inventory Management, Purchasing, Warehouse Management, Quality Control, Finance, and Executive Analytics. Each module operates as an independent service communicating through Apache Kafka for event-driven data synchronization. The system uses CQRS with PostgreSQL as the write store and Redis-powered read projections for real-time dashboards. The architecture enforces eventual consistency across modules while maintaining ACID transactions within each bounded context. ### Key Architecture Decisions **Event-Driven Integration:** All state changes are published as domain events (ProductionOrderCreated, InventoryReserved, QualityCheckPassed) to Kafka topics. Downstream services consume these events to maintain materialized views. This ensures loose coupling — the Quality Control module can be deployed independently without affecting Production Planning. **CQRS Pattern:** Write operations go through command handlers that validate business rules against the PostgreSQL write model. Read operations query denormalized Redis projections optimized for specific UI views — the production dashboard reads from a pre-computed projection updated in real-time via Kafka consumers, not from raw transactional tables. **Multi-Tenancy at Database Level:** Each factory operates within its own PostgreSQL schema, providing data isolation while sharing the same application infrastructure. Cross-factory reporting uses a dedicated analytics database populated through Kafka Connect. ## Key Features Production Planning with finite capacity scheduling considering machine availability, labor shifts, and material constraints. Inventory Management with real-time stock tracking across 8 warehouses using barcode scanning. Purchasing with automated purchase requisition generation based on reorder points and production schedules. Quality Control with inspection workflow, non-conformance tracking, and supplier quality scorecards. Finance with automated journal entries, multi-factory consolidation, and Indonesian tax compliance (e-Faktur integration). BI Dashboard with real-time OEE (Overall Equipment Effectiveness), production variance analysis, and cost-per-unit tracking. ## Technology Stack Frontend built with Next.js 15 App Router and React Server Components for island architecture — interactive dashboards render client-side while static reports use server components. Backend API layer built with NestJS following Clean Architecture with use cases, repositories, and domain entities. PostgreSQL 16 for write models with table partitioning for high-volume tables (production transactions, inventory movements). Redis Cluster for caching read projections and session management. Apache Kafka for event streaming between bounded contexts with exactly-once semantics. Docker containers orchestrated with Kubernetes on AWS EKS. Infrastructure as Code with Terraform managing VPC, RDS, ElastiCache, MSK, and EKS. ## Security Architecture Role-based access control with 12 permission roles mapped to factory-level and module-level scopes. JWT authentication with refresh token rotation. Audit logging on every state mutation with tamper-evident hashing. Data encryption at rest using AWS KMS and in transit using TLS 1.3. Network segmentation between application tier, database tier, and message broker tier using Kubernetes network policies and AWS security groups. ## Scalability Design The system is designed to handle 50,000+ production transactions per day with peak loads during shift changes. Horizontal Pod Autoscaling on Kubernetes scales API services based on CPU and custom metrics (Kafka consumer lag, request queue depth). Database read replicas serve analytics queries without impacting transactional performance. Redis Cluster shards read projections by factory ID for predictable scaling as new factories are added. ## DevOps Pipeline GitHub Actions CI/CD with automated testing (unit, integration, E2E), security scanning (Snyk, Trivy), and infrastructure validation (Terraform plan). Blue-green deployment on Kubernetes with health check gating and automated rollback on metric degradation. Centralized logging with OpenTelemetry, Loki, and Grafana. Prometheus monitoring with custom alerts for business metrics (production order backlog, inventory stockout risk). ## Results Production planning cycle reduced from 3 days to 4 hours. Inventory accuracy improved from 72% to 99.2%. Financial close time reduced from 10 days to 2 days. Supplier lead time variability reduced by 35% through data-driven purchasing. Overall equipment effectiveness improved from 68% to 84% through real-time monitoring and predictive maintenance triggers. The system now handles 50,000+ daily production transactions across 3 factories. ## Lessons Learned Event-driven architectures introduce eventual consistency that requires careful UI design — we implemented optimistic UI updates with WebSocket reconciliation for real-time dashboards. CQRS adds complexity in command-validation-read flows but pays off in query performance at scale. Multi-factory deployment requires rigorous tenant isolation testing — a schema migration that succeeds in Factory A may fail in Factory B due to data differences.

View Case Study
Artificial Intelligence

AI Customer Service Platform — Intelligent Support Automation

An AI-powered customer service platform built for a telecommunications company handling 500,000+ monthly customer interactions across WhatsApp, email, live chat, and phone. The legacy system relied on 200+ human agents using scripted responses with an average first-response time of 45 minutes and a resolution rate of only 62% on first contact. ## Business Challenge The telecom provider faced escalating support costs as their subscriber base grew to 10 million. Customer satisfaction scores were declining due to long wait times and inconsistent answers. Agents spent 60% of their time answering repetitive questions — billing inquiries, plan changes, network coverage checks — rather than solving complex problems. The knowledge base existed as 50+ PDF documents that agents searched manually. Multichannel support (WhatsApp, email, chat, phone) operated in silos with no unified customer context. ## Solution Architecture We built an AI Customer Service Platform using a Retrieval-Augmented Generation architecture. The core components include a knowledge ingestion pipeline that converts documents into vector embeddings stored in Qdrant, a RAG-based AI engine that retrieves relevant knowledge and generates contextual responses using OpenAI GPT-4o via the Sumopod provider, a human handoff system that escalates to agents when AI confidence drops below threshold, a multi-channel gateway that unifies conversations from WhatsApp Business API, email, and web chat into a single thread, and an analytics engine tracking resolution rates, response times, and customer satisfaction. ### AI Pipeline Architecture Documents (PDFs, FAQs, product specs) flow through an ingestion pipeline: text extraction → chunking (512-token segments with 64-token overlap) → embedding generation (text-embedding-3-large) → vector storage in Qdrant with metadata filters. At query time, the user message is embedded and used for hybrid search (dense + sparse) against Qdrant. Top 5 chunks are retrieved and inserted into a prompt template that includes conversation history, retrieved context, and system instructions defining the AI as a professional support agent. The LLM generates a response with confidence scoring. If confidence < 0.7, the conversation is escalated to a human agent with full context. ## Key Features AI Chatbot powered by GPT-4o with RAG for accurate, context-aware responses trained on company-specific knowledge. Knowledge Base management with versioned articles, automatic re-indexing on updates, and content quality scoring. Intelligent ticketing with automatic categorization using fine-tuned classifiers and priority assignment based on sentiment analysis. Human escalation with full conversation context transfer — agents see the AI conversation history, retrieved knowledge, and suggested responses. Multichannel support unified across WhatsApp, email, live chat, and phone with consistent AI responses. Analytics dashboard tracking containment rate, resolution time, CSAT, agent productivity, and topic clustering. ## Technology Stack Frontend built with Next.js and React for the agent dashboard and admin console. Python backend with FastAPI for the AI orchestration layer handling embedding generation, vector search, and LLM integration. OpenAI API for GPT-4o models with prompt caching optimization. Qdrant vector database for high-performance similarity search with quantization for memory efficiency. PostgreSQL for transactional data — tickets, users, conversations, knowledge articles. Redis for caching frequent queries, session state, and rate limiting. Docker containers with Kubernetes orchestration for horizontal scaling of AI workers. ## Security Customer PII is filtered before reaching the LLM — phone numbers, email addresses, and account numbers are masked with placeholder tokens. All API communication uses TLS 1.3. Knowledge base access is role-restricted. Conversation logs are encrypted at rest with AES-256. The system maintains SOC 2 Type II compliance with audit logging of every AI interaction. ## Results First-response time reduced from 45 minutes to under 30 seconds. Resolution rate on first contact improved from 62% to 85%. AI containment rate reached 72% — nearly three-quarters of inquiries handled without human intervention. Agent headcount reduced from 200 to 80 while handling 2x conversation volume. Customer satisfaction increased from 3.2 to 4.6 out of 5. Monthly support cost reduced by 60%. ## Lessons Learned RAG quality depends critically on knowledge base curation — poorly structured documents produce poor retrieval results. Investing in knowledge architecture upfront (hierarchical taxonomy, consistent formatting, regular reviews) yields compounding returns. AI confidence thresholds need continuous tuning — set too high, excessive escalation defeats the purpose; set too low, incorrect AI responses damage trust. Multichannel unification is the unsung hero — customers switching channels mid-conversation was a major pain point solved by the unified thread architecture.

View Case Study
Start Your Project

Ready to build your enterprise solution?

Discuss your software engineering needs with the HattaDev engineering team.

Start the Conversation

Free consultation. No commitment.