Tam Nguyen@backend

Service 02 / Administration

Fleet Administration & Dispatch

A backend service for planning, resources, devices, configuration, and coordination across fleet operations.

Java 17Spring BootRESTKafkaRedisPostgreSQLgRPC

Confidentiality note

This case study is generalized for confidentiality. Names, boundaries, and flows do not reproduce the private production system.

Back to portfolio

Overview

Domain: Fleet administration, planning, resources, and dispatch
Platform: The administration and coordination service within the Fleet Operations Platform

Requirements

  • Manage planning, resource, device, configuration, and reference-data workflows.
  • Validate lifecycle and assignment state for supported administration changes.
  • Provide operational context through REST and gRPC service boundaries.
  • Publish selected changes for asynchronous synchronization.
  • Support approved administration reports and exports.

Key Challenges

  • Keep planning and assignment state consistent across related records.
  • Coordinate device and resource state without hiding ownership rules.
  • Maintain cache freshness for selected administration views.
  • Separate interactive administration changes from downstream synchronization.

C4 Model

C1

System Context

People and approved external systems interacting with the Fleet Operations Platform.

C1 architecture summary

Elements
  • Fleet Operations Staff (person)
  • Administrator / Dispatcher (person)
  • Fleet Operations Platform (software system)
  • Approved Operational Data Sources (external system)
Relationships
  • Fleet Operations Staff use the Fleet Operations Platform for workflow, lookup, and reporting.
  • Administrators and dispatchers use the Fleet Operations Platform for planning, resources, and coordination.
  • The Fleet Operations Platform exchanges approved REST or gRPC requests, responses, and events with Approved Operational Data Sources.

C2

Container View

The service within the generalized Fleet Operations Platform container topology.

C2 architecture summary

Current highlighted service: Fleet Administration & Dispatch.

Elements
  • Operations Client
  • Administration Client
  • Fleet Operations Core service
  • Fleet Administration & Dispatch service
  • Fleet Data Intelligence Hub service
  • Kafka event broker
  • Operations PostgreSQL
  • Operational Redis cache
  • Administration PostgreSQL
  • Administration Redis cache
  • Intelligence PostgreSQL
  • Elasticsearch search index
Relationships
  • The Operations Client calls Fleet Operations Core through REST or gRPC.
  • The Administration Client calls Fleet Administration & Dispatch through REST or gRPC.
  • Fleet Administration & Dispatch supplies plans, resources, and configuration to Fleet Operations Core through REST or gRPC.
  • Fleet Operations Core requests lookup and search data from Fleet Data Intelligence Hub through REST or gRPC.
  • Fleet Administration & Dispatch requests aggregated lookup data from Fleet Data Intelligence Hub through REST or gRPC.
  • Fleet Operations Core publishes operational events to Kafka.
  • Fleet Administration & Dispatch publishes reference and coordination events to Kafka.
  • Kafka delivers synchronization events to Fleet Data Intelligence Hub.
  • Fleet Operations Core uses Operations PostgreSQL and the Operational Redis cache.
  • Fleet Administration & Dispatch uses Administration PostgreSQL and the Administration Redis cache.
  • Fleet Data Intelligence Hub uses Intelligence PostgreSQL and the Elasticsearch search index.

C3

Component View

Generalized internal components and their primary responsibilities.

C3 architecture summary

Elements
  • REST and gRPC API
  • Planning and Coordination Use Cases
  • Resource and Device Use Cases
  • Configuration and Reference Use Cases
  • Persistence Adapter
  • Cache and Coordination Adapter
  • Service Integration Adapters
  • Event Adapter
  • Report and Export Renderer
  • PostgreSQL
  • Redis and ShedLock
  • Related Platform Services
  • Kafka
Relationships
  • The REST and gRPC API delegates to planning and coordination, resource and device, and configuration and reference use cases.
  • All three use-case groups access the Persistence Adapter.
  • Planning and Coordination Use Cases and Resource and Device Use Cases access the Cache and Coordination Adapter.
  • Configuration and Reference Use Cases access Service Integration Adapters.
  • Planning and Coordination Use Cases access the Event Adapter and Report and Export Renderer.
  • The Persistence Adapter accesses PostgreSQL.
  • The Cache and Coordination Adapter accesses Redis and ShedLock.
  • Service Integration Adapters call Related Platform Services through REST or gRPC.
  • The Event Adapter publishes events through Kafka.

Main Flow

  • An administrator submits a planning, resource, device, or configuration request.
  • The API boundary validates the request and available authorization context.
  • The use case applies lifecycle, assignment, and consistency rules.
  • The service persists the approved change and updates explicit cache state where relevant.
  • It exposes updated context synchronously or publishes a change event.
  • Operations Core and Data Intelligence Hub consume the appropriate result through their boundaries.

My Contributions

  • Developed administration APIs for supported planning, resource, device, and configuration flows.
  • Worked on database queries and validation for lifecycle and assignment state.
  • Used Redis for selected cache and coordination responsibilities.
  • Contributed to Kafka event integration for supported changes.
  • Integrated related services through REST and gRPC and supported approved reports.

Tech Stack

Java 17Spring BootRESTgRPCKafkaRedisElasticsearchPostgreSQLShedLock

Reliability & Security

  • Validate lifecycle and assignment state before supported updates.
  • Keep cache and coordination responsibilities explicit.
  • Separate synchronous administration responses from asynchronous propagation.
  • Omit private configuration and operational identifiers from public material.

Trade-offs / Design Decisions

  • Centralized administration context improves consistency but creates an important service dependency.
  • Distributed coordination helps selected workflows but requires bounded lock ownership.
  • Event propagation reduces direct coupling while accepting delayed downstream visibility.

Outcome / Impact

  • Provided a consistent administration boundary for planning and operational resources.
  • Supplied controlled context to operational workflows and downstream data synchronization.

Lessons Learned

  • Model lifecycle transitions explicitly instead of inferring them from records.
  • Keep cache, coordination, and persistence responsibilities separate.
  • Publish only the events required by downstream service contracts.

Related Platform Services

Service 01 / Operational CoreFleet Operations CoreThe central backend service for fleet workflows, interactive lookup, operational statistics, and document generation.Service 03 / Data IntelligenceFleet Data Intelligence HubA data-focused backend service for multi-source synchronization, aggregation, operational search, and normalized lookup.