Academic / backend platform
Modular Monolithic Backend for Fleet Management System
An architecture-led backend that keeps one Fastify REST and SSE deployment while composing selected, independently versioned domain packages.
- Period
- Jul 2025 - Jun 2026
- Role
- Backend developer / final project
- Delivery
- Research and testing assembly
Overview
Context before technology.
Runner, Nusakit SDK, and seven active business modules define lifecycle, typed synchronous contracts, event intake, persistence, and package assembly boundaries.
Architecture map
One deployment. Explicit internal boundaries.
- 01
Runner
Fastify host, configuration, lifecycle orchestration, migrations, REST, SSE, and worker startup.
- 02
Nusakit
Module contract, dependency-first loading, typed service contracts, dependency injection, and runtime bridge.
- 03
Domain packages
Auth, customer profile, tracking, vehicle, route, driver, and schedule capabilities with owned schemas.
- Client
Applications
REST and SSE
-> - Bun
Fastify main process
Runner, Nusakit, and module handlers
-> - IPC
Unix domain socket
Newline-delimited local messages
-> - Node
Kafka worker
node-rdkafka consumption
-> - Data
Operational sources
Kafka, schemas, PostgreSQL, and PostGIS
- 01
Develop
Local workspace links runner, SDK, and domain packages.
- 02
Publish
Versioned packages reach private registry through publication jobs.
- 03
Assemble
Runner template installs selected versions and enabled-module configuration.
- 04
Run
One backend starts migrations, modules, REST, SSE, and Kafka worker.
Design objective
Fleet operations span identity, customer, vehicle, route, driver, schedule, tracking, and telematics domains. The project kept those boundaries explicit without turning every domain into a separately deployed service.
The result is one backend deployment unit whose selected business packages are composed by configuration. Module selection and package versioning happen during assembly, not through runtime hot-swapping.
Three architectural pillars
Runner provides Fastify, shared infrastructure, module configuration, startup order, centralized migrations, REST, SSE, and the Kafka worker lifecycle.
Nusakit is internal modular-runtime SDK: module contract, dynamic loading, dependency-first ordering, typed dependency-injection registry, and lazy contract resolution. Seven active packages then own domain behavior and database schemas.
Communication model
Synchronous module collaboration uses typed Nusakit contracts. Providers register an explicit interface; consumers resolve it without importing the provider implementation at runtime.
Loose in-process events handle internal asynchronous reactions. Kafka handles external asynchronous intake. These channels are deliberately distinct: only the synchronous contract registry is globally type-backed in the current runner.
Hybrid runtime and operational data
Bun hosts Fastify, REST, SSE, module handlers, and local IPC. It starts a Node.js child process for node-rdkafka consumption; newline-delimited messages cross a Unix domain socket inside the same backend deployment.
Tracking and vehicle modules process already structured location and telematics messages, use Schema Registry and Protobuf decoding where needed, then persist operational state for REST and SSE delivery. Raw vehicle protocol decoding belongs upstream, outside this backend scope.
Persistence and assembly
Domain modules own schemas within one PostgreSQL instance, with PostGIS where spatial behavior is needed. The runner collects module migrations, namespaces them, and coordinates execution centrally with an advisory lock.
Local development links packages in a multi-package, multi-repository workspace. Production-style assembly installs selected versioned packages from a private registry into the runner template. Publication jobs publish packages; they do not establish full CI/CD or automated deployment.
Evaluation boundary
Thesis evaluation documents representative package assemblies, migrations, startup, health behavior, REST and SSE responses, and operational-data paths in a research/testing LXC environment.
This is not a production, performance, throughput, latency, exactly-once, DLQ, replay, or full-test-suite claim. Current runner code may also postdate the evaluated thesis revision.
Working set