Tam Nguyen@backend

Service 01 / Operational Core

Fleet Operations Core

The central backend service for fleet workflows, interactive lookup, operational statistics, and document generation.

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 operations, workflow, lookup, and reporting
Platform: A core service within the Fleet Operations Platform

Requirements

  • Expose REST and gRPC interfaces for operational workflow and lookup use cases.
  • Apply workflow and state rules before supported persistence changes.
  • Use administration context for planning, resource, and configuration needs.
  • Publish selected operational events for asynchronous synchronization.
  • Generate approved document outputs for supported operational flows.

Key Challenges

  • Keep synchronous request flows consistent across service boundaries.
  • Coordinate relational data, explicit cache state, events, and search-backed reads.
  • Keep workflow transitions and ownership rules visible in use-case orchestration.
  • Generate documents without coupling templates to transport-layer contracts.

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 Operations Core.

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
  • Workflow and Query Use Cases
  • Persistence Adapter
  • Cache Adapter
  • Service Integration Adapters
  • Event Adapter
  • Document Renderer
  • PostgreSQL
  • Redis
  • Related Platform Services
  • Kafka
Relationships
  • The REST and gRPC API delegates requests to Workflow and Query Use Cases.
  • Workflow and Query Use Cases coordinate the Persistence Adapter, Cache Adapter, Service Integration Adapters, Event Adapter, and Document Renderer.
  • The Persistence Adapter accesses PostgreSQL.
  • The Cache Adapter accesses Redis.
  • Service Integration Adapters call Related Platform Services through REST or gRPC.
  • The Event Adapter publishes events through Kafka.

Main Flow

  • An operations client submits a request through a REST or gRPC interface.
  • The API boundary validates and maps the request to a use case.
  • The use case applies workflow, state, and ownership rules.
  • The service accesses relational data and explicit Redis state where appropriate.
  • It requests administration context or aggregated data when the workflow requires it.
  • It returns a normalized response, generates a document, or publishes an operational event.

My Contributions

  • Developed REST APIs and mappings for supported operational workflows.
  • Worked on PostgreSQL queries and use-case orchestration.
  • Integrated related services through REST and gRPC boundaries.
  • Used Redis for explicit cache and short-lived workflow state.
  • Contributed to selected Kafka event paths and document-generation flows.

Tech Stack

Java 17Spring BootRESTKafkaRedisElasticsearchPostgreSQLgRPCOpenFeignPDF and document generation

Reliability & Security

  • Validate requests and supported ownership context at the service boundary.
  • Keep cache responsibilities explicit and separate from relational truth.
  • Use bounded integration behavior for selected synchronous and asynchronous paths.
  • Exclude private data and production details from public artifacts.

Trade-offs / Design Decisions

  • Explicit boundary mapping improves isolation but adds mapping maintenance.
  • Asynchronous events reduce direct coupling but introduce eventual consistency.
  • Document generation supports operational workflows but adds template lifecycle work.

Outcome / Impact

  • Provided a clear backend boundary for supported operational workflows and lookup use cases.
  • Connected interactive workflows with administration context and read-oriented data services.

Lessons Learned

  • Keep transport contracts separate from use-case orchestration.
  • Make workflow state and ownership rules explicit before persistence changes.
  • Choose synchronous or asynchronous integration from consistency needs.

Related Platform Services

Service 02 / AdministrationFleet Administration & DispatchA backend service for planning, resources, devices, configuration, and coordination across fleet operations.Service 03 / Data IntelligenceFleet Data Intelligence HubA data-focused backend service for multi-source synchronization, aggregation, operational search, and normalized lookup.